# DYCE Documentation > Documentation for DYCE apps by Singhammer IT Consulting This file contains all documentation content in a single document following the llmstxt.org standard. ## DYCE API Connector for Dataverse # Welcome to DYCE API Connector for Dataverse **DYCE API Connector for Dataverse** provides essential API pages within Business Central that facilitate data exchange, allowing organizations to maintain consistent customer, contact, and opportunity information across both platforms. The solution works in conjunction with wysa's [SalesCentral](/docs/acd/administration/setup-integration.md#SalesCentral) and [DataBridge](/docs/acd/administration/setup-integration.md#DataBridge) technology to deliver a complete sales and CRM integration. The solution is designed to operate reliably in the background while providing meaningful enhancements to the user experience. With proper setup and ongoing support from **Singhammer IT Consulting AG**, you can achieve a unified view of your customer and sales data across all platforms. For full integration, DataBridge and SalesCentral are deployed and configured as part of the solution. Please contact **Singhammer IT Consulting AG** to coordinate setup, customizations, and ongoing support. ## Features of API Connector for Dataverse * **Bi-directional synchronization** between Business Central and Microsoft Dynamics 365 Sales (Dataverse) * **Real-time data exchange** through secure API connections * **Seamless integration** with existing Business Central workflows * **Enhanced visibility** with Dataverse IDs and sales information directly in Business Central ## Required Components * **[SalesCentral](/docs/acd/administration/setup-integration.md#SalesCentral)** - wysa's sales solution for process alignment * **[DataBridge](/docs/acd/administration/setup-integration.md#DataBridge)** - Azure-hosted mapping and synchronization engine ## Supported Editions Premium and Essential edition of Microsoft Dynamics 365 Business Central. ## Supported Markets All markets supported by Microsoft Dynamics 365 Business Central. ## Supported Languages **DYCE API Connector for Dataverse** is available in English and German. --- ## DYCE Cockpit # Welcome to DYCE Cockpit By using **DYCE Cockpit**, the handling of workflows and complex processes in Business Central is refined. Relevant information about tasks and to-dos, as well as important data and thresholds are actively provided. You would like to have the possibility to configure a part of the Role Center yourself by displaying your relevant information in the tiles? With **DYCE Cockpit** this wish becomes reality. ## Important data records visible at a glance - directly in your Business Central dashboard With this DYCE app, every employee sees all open to-dos, processes or important data which correspond to the underlying filter. All necessary information is displayed in the form of individual tiles in the Role Center. Thanks to the clear display, users save a considerable amount of time. You can display your most important processes, key figures and to-dos in the Role Center of Business Central. A total of 24 freely definable storage locations are available for this purpose. For even more clarity, you can also use colors for the descriptions in the tiles (e.g., as soon as a threshold value is exceeded). In this way, you can clearly signal whether immediate action is required. ## Features of Cockpit * Convenient and time-saving display of your most important processes and data in the Role Center * Monitoring of data records based on threshold values * Automatic updating of data records through dynamic date filters * Create and copy new filters based on defaults ## Use Cases * **My offers** In the sales process, when an opportunity reaches a certain status, a sales quote is created. The responsible employee is assigned to the quote. Employees want to see the quotes they are responsible for. * **Invoice orders** One of the tasks of the Project Office team is to create invoices for delivered orders. For this, colleagues need an indicator that shows them that particular items have been shipped. However, the colleagues do not create each invoice individually but use batch processing for this purpose due to time constraints. At least three orders should be processed at once. At the same time, however, employees are urged not to leave too many orders unbilled. * **Expiring quotations** The Sales team monitors the validity of quotes to follow up on old quotes without a response. To do this, sales reps have created a cue that shows them all quotes that exceed the entered validity within a week. This way, they avoid overlooking a quote and losing a potential deal. * **Post Invoices** Posting invoices and credit memos is one of the tasks in the Financial Accounting team. Since employees have to keep track of many different tasks, they would like to save themselves the time of steadily manual checking the respective items. They would like to react as soon as an invoice or credit memo is ready for posting. ## Supported Editions Premium and Essential edition of Dynamics 365 Business Central. ## Supported Countries All countries supported by Dynamics 365 Business Central. ## Supported Languages **DYCE Cockpit** is available in English, French, German and Serbian. --- ## DYCE Connector for Jira Service Management # Welcome to DYCE Connector for Jira Service Management **DYCE Connector for Jira Service Management** is a comprehensive integration platform for synchronizing Business Central data with Jira. It bridges the gap between your Business Central and project management workflows, enabling seamless, automated data synchronization between the two systems with full control over what gets synchronized and when. ## Features * **Customer and Contact synchronization** Out of the box, **DYCE Connector for Jira Service Management** supports synchronizing Customers and Contacts from Business Central to Jira organizations and Jira customers. Sync status and the linked Jira ID are displayed directly on the Customer and Contact cards. * **Asset synchronization** Customers, Contacts, Projects and Service Assets can additionally be synchronized to Jira as Jira Assets (Insight) objects, using a configurable schema of object types and attributes that mirrors the structure of Jira Assets itself. * **Flexible entity and field mapping** Define exactly which fields are transferred for which Jira entity. Both Jira standard fields and detail fields are supported, so that you have full control over the data structure on the Jira page. * **Automatic activation** Synchronization can be triggered automatically based on configurable rules. Rules evaluate record events and can check specific field changes, so only relevant records are queued. * **Automatic assignment to Jira spaces** Newly created Jira organizations as well as Jira customers can be automatically added to one or more Jira spaces. A filter can be configured per space so that only customers or contacts matching specific criteria, such as a customer group or country, are assigned. This keeps your Jira spaces organized without any manual steps. * **Delta synchronization** When a record is modified, only the changed fields are included in the synchronization payload. This minimizes API calls and keeps the integration efficient, even in environments with high data volumes. * **Asynchronous message queue** Integration messages are processed asynchronously via a built-in message queue. Each message is tracked with a status and can be retried automatically after a configurable delay if processing fails. ## Supported Versions Premium and Essential edition of Microsoft Dynamics 365 Business Central. ## Supported countries All markets supported by Microsoft Dynamics 365 Business Central. ## Supported languages **DYCE Connector for Jira Service Management** is available in English and German. --- ## DYCE Document Tracker # Welcome to DYCE Document Tracker It can be tedious to quickly find all the documents involved in a certain process in the system, for example when a customer has a question about a sales invoice. With **DYCE Document Tracker** this is no longer a problem. You always have an overview of all documents that belong to a transaction. You can access **DYCE Document Tracker** from the cards of most documents or via the search - and a list of all transactions and documents related to the outgoing document is instantly available. ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported languages **DYCE Document Tracker** is available in English and German. --- ## DYCE Easy Bundle Seller # Welcome to DYCE Easy Bundle Seller The app **DYCE Easy Bundle Seller** helps you to structure your sales quotes and orders, even with multiple items, clearly and user-friendly. Product bundles can be created and used. They are complemented by the possibility to use formatting to highlight individual elements. All these functions are of course also supported in print. Would you like to be able to design your sales documents flexibly? Do you see printed receipts as your company's business card? Then **DYCE Easy Bundle Seller** is exactly what you need. ## Simplify complex sales quotes! With **DYCE Easy Bundle Seller** you can easily combine several products and services. You decide whether you want to predefine this set in the item master data or create it flexibly. Bundling can be used to communicate complex offer structures to the customer in a simplified way. It is possible to select which information the customer should receive and which is only for internal processing of the bundle. ## Formatting **DYCE Easy Bundle Seller** offers you the very useful feature to use custom formatting to highlight individual items. Formatting is of course also supported when printing the customer document. ## Features of Easy Bundle Seller * **Clear structuring of sales documents** You decide what you want to print on the customer document: only the sales bundle or an individual listing of all components. Throughout the process, the bundle is treated as an independent product. * **Simple pricing of a bundle** Simply combine several components into a new stand-alone product. The price of the bundle is based on the prices of the individual components. If these change, the bundle price is automatically adjusted. Discounts are distributed evenly across all components. * **Formatting for highlighting and hiding** Do you want to hide the fact that the bundle consists of different product categories (e.g. hardware and software)? Then use the formatting option to control the visibility of the individual parts. ## Supported Editions Premium and Essential edition of Microsoft Dynamics 365 Business Central. ## Supported Markets All markets supported by Microsoft Dynamics 365 Business Central. ## Supported Languages **DYCE Easy Bundle Seller** is available in English and German. --- ## DYCE E-Document for Germany # Welcome to DYCE E-Document for Germany The **DYCE E-Document for Germany** app extends the standard e-documents module of Microsoft Dynamics 365 Business Central with full support for **EN16931 compliant electronic invoices** with regard to the relevant **DYCE-specific** functionalities. It enables the correct generation of **XRechnung (UBL Invoice)** and **ZUGFeRD (CII)** without the need to adapt existing sales processes or PDF layouts. The app is **immediately ready to use** and requires **no configuration** or **permissions**. ## Based on the Business Central standard Business Central already has options for electronic invoicing as standard. Understandably, DYCE features that go beyond this are not included. Therefore, their setup is not explained in detail here. **DYCE E-Document for Germany** ensures compatibility - without any configuration effort. ## Purpose of the app Various DYCE apps have an influence on document creation, e.g. through: * Bundles and nested document lines (**[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)**) * Extended description texts (**[DYCE Happy Texts](/docs/ht/welcome.md)**) * Service billing with service periods (**[DYCE Project Billing](/docs/pb/welcome.md)**) * Fixed Price items (**[DYCE Project Billing](/docs/pb/welcome.md)**) * Serial number handling * Groupings and formatting in documents/PDF These functionalities go beyond the Business Central standard, which means de facto incompatibility. **DYCE E-Document for Germany** ensures that **all relevant DYCE functionalities are correctly translated into EN-16931-compliant XML invoices** - PDF and e-invoice thus match. ## Central functions Once the app is installed, it reacts independently and automatically to the relevant DYCE functionalities. Before a sales document is posted - more precisely, when the document is released - it ensures that the prerequisites for successful processing of the e-invoice at a later point in time are met. These points are explained in more detail below. ### Precise Bundle Export (DYCE Easy Bundle Seller) #### Print line Outside of bundles, only text lines may have the value **Print line**=*No*. The following applies to bundles: **Case A: Bundle header is printed** * Bundle line: **Print line**=*Yes* * Component lines can have **Print line**=*Yes* or **Print line**=*No*. * Result (in both cases): Only the bundle header is exported to the e-document, components are ignored. **Case B: Components are printed** * Bundle line: **Print line**=*No* * All component lines must have **Print line**=*Yes*. * Result: The bundle header is not exported, components are exported. Further rules: * Subtotals, formatting or page breaks (**New page**=*Yes*) are ignored during export. * Invalid settings or combinations block posting (error message). #### Print quantity only This field is only relevant within bundles. Outside bundles, only text lines may have the value **Print quantity only**=*Yes*. If a line is exported to an e-document, this line must have **Print quantity only**=*No*. #### Print line discount % The behavior in e-documents must match the PDF printout. Line discounts must also be hidden in the e-document in all cases in which they are hidden in the printout. ### Extended description texts (DYCE Happy Texts) Extended descriptions are exported to the e-document: * Multi-line, clearly structured * Fully XRechnung and ZUGFeRD compliant (although not required by the specification) ### Serial number export (DYCE Essentials) * Determination via item ledger entries * Support for multiple serial numbers per line * Structured, traceable output ### Service billing (DYCE Project Billing) #### Service periods The service period must be specified for each line item. This is determined from the project ledger entries belonging to the line item: * Start date = earliest service date * End date = latest service date #### Fixed price billing For Fixed Price items, the export to e-documents must reflect the logic of the document printout: * Quantity = 1 * Line amount corresponds to unit price :::tip Buyer reference In Germany, the **Buyer reference** field is mandatory for e-documents. In the **E-Document Services**, you can decide for each configuration which field is to be used for this: either **Your Reference** from the document header (selection *Your Reference*) or the **E-Invoice Routing No.** from the customer card (selection *Customer Reference*). The **E-Invoice Routing No.** from the customer card is always used for the e-document for the *Customer Reference* selection. In this case, **Your Reference** from the document header is also transferred to the XML. For the selection *Your Reference*, the field of the same name from the *header of the sales order* is used for invoices *for a sales order*. For invoices for professional services *without a sales order reference*, the field of the same name from the *Project card* is used. Regardless of the selection, a filled **Your Reference** is always exported as the buyer's order reference. In XRechnung it replaces the **External Document No.**; in ZUGFeRD it replaces an order number, return order number or **External Document No.** that would otherwise be used as the order reference. ::: ### Integration with Business Central documents * Support for **XRechnung (UBL Invoice)** and **ZUGFeRD (CII)** * PDF can be attached automatically (according to the existing and set up logic for e-documents) * Support for validation services ## Advantages **EN16931 conformity** * Consistency between PDF and XML * No configuration necessary * Future-proof for German B2B e-invoices ## Supported editions Premium and Essential edition of Microsoft Dynamics 365 Business Central. ## Supported markets The app is only available in Germany. ## Supported languages The app itself does not have any text output. This point is therefore not relevant. --- ## DYCE Feature Suite for Subscription Billing # Welcome to DYCE Feature Suite for Subscription Billing As the name suggests, this is an app that includes features that extend the functionality of Microsoft Subscription Billing. ## Tier prices Tiered pricing is a pricing model in which the price per unit varies depending on the quantity purchased or consumption. The aim is to motivate customers to purchase larger quantities or use more intensively by offering volume discounts or graduated tariffs. This model is often used in retail, services and subscription business models. The basic principle is that the price per unit decreases as the quantity increases. The price tiers are set in defined quantity ranges, for example 1-49 units, 50-99 units and over 100 units. In retail terms, this means volume discounts for products. There are two common methods for calculating tiered pricing, both of which are supported with **DYCE Feature Suite for Subscription Billing**: * **Flat-Tier Pricing** All units are charged at the price of the applicable quantity level. * **True-Tier Pricing** Each quantity level is taken into account separately and calculated in total. [Tier prices](/docs/fssb/tier-pricing.md) are maintained via the Sales Prices in Business Central standard. ## Considering existing subscriptions in tier pricing When a customer purchases additional licenses, an existing subscription can be [selected on the sales line](/docs/fssb/tier-pricing.md#considering-existing-subscriptions) so that the existing quantity is factored into tier price determination. This ensures the correct price tier is applied based on the total quantity, and the selected subscription is updated automatically on shipment. ## Tier pricing in Usage-Based Billing Tier pricing is also taken into account during usage data processing. When **Usage Based Pricing** is set to *Usage Quantity* on a subscription line, the applicable tier is determined by the imported quantity and used as the billing base — following the same Flat-Tier or True-Tier logic as for subscription lines. See [tier pricing](/docs/fssb/tier-pricing.md#tier-pricing-usage-data) for details. ## Preassigning of contracts in sales To simplify the process for billing subscriptions, the customer subscription contract via which the subsequent billing is to take place can already be [selected](/docs/fssb/preassigning-contracts.md) during the sales process, i.e. already in the sales line. In addition to the creation of the subscription, the related subscription lines are retrieved in the specified customer subscription contract. ## Usage data bundles If a bundle contains a usage-based component, the quantities of all other components and of the bundle itself can be [adjusted automatically](/docs/fssb/usage-data-bundles.md) whenever the quantity of the usage-based component changes, for example when usage data is processed. ## Comment lines on contract invoices Comment lines in customer subscription contracts can be [attached to a specific line](/docs/fssb/contract-comment-lines.md) using the **Attached to Line No.** field. When an invoice is created, attached comment lines are transferred to the invoice alongside the contract line they belong to. ## Availability This is the main app of **[DYCE Feature Suite for Subscription Billing](/docs/appsuites/fssb.md)** and cannot be obtained without it. Further information can be found at the link provided. ## Supported Editions Premium and Essential edition of Microsoft Dynamics 365 Business Central. ## Supported Markets All markets supported by Microsoft Dynamics 365 Business Central. ## Supported Languages **DYCE Feature Suite for Subscription Billing** is available in English and German. --- ## DYCE Essentials # Welcome to DYCE Essentials The **DYCE Essentials** app is included with several other DYCE apps. It is a collection of various small features that can be used in all related DYCE apps. More information about these apps can be found [here](/docs/general/essentials/activation.md). ## Features of Essentials **DYCE Essentials** includes the following features: * Automatic [dimension](/docs/general/essentials/customer-dimension.md) for customers * [Position numbers](/docs/general/essentials/position-numbers.md) in sales documents * [Print Preview](/docs/general/essentials/print-preview.md) of sales documents that have not yet been posted * [Report Configuration](/docs/general/essentials/report-configuration.md) * Additional [layouts](/docs/general/essentials/report-extensions-layouts.md) ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported languages **DYCE Essentials** is available in English and German. --- ## DYCE Happy Texts # Welcome to DYCE Happy Texts The **DYCE Happy Texts** app solves one of the fundamental challenges that has always existed in Microsoft Dynamics 365 Business Central: formattable long texts and images in sales documents! These long texts are available both as pre- and post-texts (Header and Footer texts) for sales documents and as extended descriptions for the products in the document lines. Of course, they can also be printed using on-board tools. You would like to have the possibility to create your sales documents with a personal salutation and a farewell? Detailed product descriptions incl. images represent an added value for you and are important to you? Then **DYCE Happy Texts** is exactly what you need! ## Use templates and automation Not only can you add a personal greetings and goodbyes to your offers with this extension for Business Central, but you can also use templates and have pre- and post-texts added automatically. With appealing and informative offers, you strengthen customer loyalty and save valuable resources yourself. ## Features of Happy Texts * [Formattable texts without length restrictions](/docs/ht/continuous-texts.md) * Personal salutations and farewells in sales documents * Support for image files * [Use of templates](/docs/ht/text-templates.md) * Integration into sales processes * Automatic pre- and post-texts * Editor as add-in ## Supported Editions Premium and Essential edition of Microsoft Dynamics 365 Business Central. ## Supported Markets All markets supported by Microsoft Dynamics 365 Business Central. ## Supported Languages **DYCE Happy Texts** is available in English and German. --- ## DYCE IT-Business Toolkit # Welcome to DYCE IT-Business Toolkit The **DYCE IT-Business Toolkit** app is a collection of various features that are mainly needed in the IT industry, but are not limited to it. In addition to the [features](#features-of-it-business-toolkit), it also includes other apps that can be used for free in conjunction with **DYCE IT-Business Toolkit**. These are the following apps: * **[DYCE Smart Workflow Tool](/docs/swt/welcome.md)** * **[DYCE Cockpit](/docs/cp/welcome.md)** * **[DYCE Document Tracker](/docs/dt/welcome.md)** * **[DYCE Essentials](/docs/general/essentials/welcome.md)** * **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** * **[DYCE Happy Texts](/docs/ht/welcome.md)** * **[DYCE Record History & Favorites](/docs/rhf/welcome.md)** * **[DYCE Price List](/docs//pli/welcome.md)** If you think the features and included apps can be put to good use in your business, then the **DYCE IT-Business Toolkit** is for you. ## Work more efficiently and customer-centred – thanks to DYCE The app significantly extends the Business Central standard. For example, it allows you to create a purchase order which is automatically linked to a sales order. You also have the option of conveniently importing different supplier configurations into your quote as well as creating individual payment plans for your customers. ## Features of IT-Business Toolkit * Automatic calculation of [sales margin](/docs/ibt/margin-calculation.md) - either as a trade margin or as a markup * [Payment Plan](/docs/ibt/payment-plan.md) for Sales Orders * Import of [calculations](/docs/ibt/calculation-import.md) * [Sales-related procurement](/docs/ibt/sales-related-procurement.md) * [Licensee](/docs/ibt/licensee.md) * [Regulate Unit Cost](/docs/ibt/regulate-unit-cost.md) * [Alternative and Optional Positions](/docs/ibt/alternative-optional-positions.md) in sales quotes ## Use Cases For many sales quotes, supplier offers are obtained first. Often these offers are available in the form of a configuration ( e.g. server configuration - comparable to the configuration of a car). Converting these configurations into a customer quotation is time-consuming: Line by line, the items must be entered in the quotation and, if necessary, first created, or an item line receives a great deal of additional information that must be entered manually as text. If the supplier configuration changes, changing the quotation is therefore also very time-consuming and error-prone. These offers / configurations often have a special project price granted by the manufacturer. This is stored with the supplier in the form of a special condition. So that these special conditions take effect with the order, the special condition (in the form of a number) must be indicated. This can easily be forgotten during the ordering process and the special conditions may then not be applied to the order. In addition, this type of quotation often does not use fixed item prices, but adds a margin. This is not possible in Business Central Standard. A special type of payment conditions is the use of a payment plan, which, for example, stipulates that an invoice is only issued once certain milestones have been reached - regardless of the services actually provided. However, Business Central Standard can only work with manual prepayments, or split a total invoice into several partial payments. Payment plans are not part of the Business Central Standard functionality. ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported languages **DYCE IT-Business Toolkit** is available in English and German. --- ## DYCE Managed Service Providers # Welcome to DYCE Managed Service Providers **DYCE Managed Service Providers** extends partial shipments via Warehouse Shipments and order-oriented procurement. It makes it significantly easier and more efficient to work with Warehouse Shipments and Purchase Orders. Furthermore, it enables you to create Purchase Orders based on the quantity that is actually supposed to be shipped to the customer. ## Features & benefits of Managed Service Providers * **Partial shipments with Warehouse Shipments based on the Sales Order** In Business Central, only one Warehouse Shipment can be created per Sales Order. With **DYCE Managed Service Providers**, multiple Warehouse Shipments can be used per Sales Order. Items and quantities can be selected to split the Sales Order into multiple shipments. * **Purchasing according to demand** If a customer requests a large quantity of one particular item, this does not necessarily mean that the entire quantity has to be purchased immediately. Instead of purchasing everything at once, that is in all Sales Orders, purchases can be created based on selected Warehouse Shipments (planned partial shipments). In this way, purchasing can be tailored to the quantity that is supposed to be shipped. * **Different Ship-To address** A different shipment address can be specified before and after the creation of a Warehouse Shipments. A large customer with different shipment addresses can thus be processed easily and clearly in one Sales Order. * **Automatic reservation from the warehouse** The items can be reserved from the Warehouse, then Warehouse Shipments are created. The quantity of each item can be adjusted before creating a Warehouse Shipment. Accordingly, only the quantities, which are going to be shipped to the customer are reserved. * **Create Purchase Orders in a central overview** All items that are in Warehouse Shipments and need to be ordered are displayed in the new **Purchase Requisition** page. * **Combine multiple Warehouse Shipments in one Purchase Order** Several Warehouse Shipments can be combined into one Purchase Order on the **Purchase Requisition** page. The combination is done automatically when the Purchase Orders are created. * **Assignment to existing Purchase Orders** Warehouse Shipments can be added to existing Purchase Orders. * **Special Bid** **DYCE Managed Service Providers** is compatible with [Special Bids](/docs/ibt/sales-related-procurement.md#process). * **Drop Shipment** Drop Shipments can be used in Warehouse Shipments and thereby the process of creating Purchase Orders remains similar. * **Commissioning document** (coming soon) When posting a Purchase Order (receipt goods), the **Quantity to be Shipped** is automatically set in the Warehouse Shipments. To facilitate the goods issue, the Warehouse Shipments can be printed directly with quantities and items. ## Supported Versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported languages **DYCE Managed Service Providers** is available in English and German. --- ## DYCE Project Billing # Welcome to DYCE Project Billing With **DYCE Project Billing** you can easily bill for services. Flexible billing models support you and ensure significant time savings. Are you looking for a management system for Microsoft Business Central with which you can offer and invoice all services in the form of projects? The workflow should be efficient and traceable? **DYCE Project Billing** is the solution for you. ## Billing for services is now easier than ever - with DYCE Project Billing By using our management app, you can offer services in the same way as retail items and have them commissioned by customers. They can be bundled as projects and billed via project orders or separately from them. Choose between a capped budget, which can be increased or decreased as needed, and a fixed price, which is always billed as a whole. You can also bill services according to the actual time and effort involved (Time & Material). With our time tracking software **[DYCE Time Tracking](/docs/web/tt/welcome.md)** project managers always have an overview. Employees record their billable times. These times can then be checked by the project management, corrected if necessary and released for billing. ## Features of Project Billing * Linking of Sales Orders and Projects * Creation of tasks for sales orders and scheduling in the budget * Different types of billing models (time & material, budget, fixed price) * Acquisition of task-relevant external services and resources * Automatic rounding up of Time Recordings (example: 50 min to 1h) * Automatic adding of details about the service on the invoice ## Supported versions This app supports both Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported Countries Users worldwide can use this application. ## Supported languages **DYCE Project Billing** is available in English and German. --- ## DYCE Price List Import # Welcome to DYCE Price List Import Importing and processing supplier price lists into the ERP system requires a high level of accuracy for both new items and existing items. By automatically updating the purchase prices of catalog items and items, all steps can be done centralized. The creation of various import templates provides the necessary flexibility to import different price lists from multiple suppliers. ## Import and processing of price lists Price lists are structured differently for each supplier and often include many data records, which makes manual maintenance of purchase prices time-consuming. In addition, they often contain data that should not be imported at all, e.g. announcements that are not yet valid at the time of processing. **DYCE Price List Import** allows you to import price lists from different vendors very easily into Microsoft Dynamics 365 Business Central. The price list can be filtered during import and particular fields can be specifically replaced with specified values. All imported lines are displayed in an overview. During processing, the purchase prices are updated in the respective catalog item and, if applicable, the related item. If the catalog item does not yet exist, it is automatically created during import. If an item is offered by more than one supplier, the purchase prices of all suppliers are maintained on the same catalog item or item. :::note Note **DYCE Price List Import** can currently only process files in csv format. ::: ## Supported Editions This app supports both **Essential** and **Premium** editions of Microsoft Dynamics 365 Business Central. ## Supported Markets Available in **all markets** supported by Microsoft Dynamics 365 Business Central. ## Supported languages **DYCE Price List Import** is available in English and German. --- ## DYCE Prepaid Services # Welcome to DYCE Prepaid Services With **DYCE Prepaid Services** it is possible to pre-sell professional services, subscriptions or budgets of any kind, which can be consumed afterwards via different processes. The app extends the functionality of **[DYCE Project Billing](/docs/pb/welcome.md)**. A **Prepaid Service** can consist of an amount or a quantity that is increased as needed. It does not need to be created each time. It can be topped up via a Sales Order, Customer Subscription Contract or manually. In addition, a validity can be defined, after which the remaining balance expires. Additions and disposals are tracked in detail for each Prepaid Service. For the output of these details a statement is available, which can be provided to the customer e.g. by mail. An existing budget can be consumed via a sales document by linking a Prepaid Service to a position. Alternatively, the link can also be made without a reference to a Sales order via a [Project Task or Project Planning line](/docs/pb/masterdata/project-task-planning-line.md). During invoicing, the customer receives a zero invoice as long as there is still budget available. Only when this is exhausted the difference will be invoiced. Alternatively, the budget can be replenished. In the case of a Credit Memo (e.g. when services are cancelled), the Prepaid Service is also automatically corrected. When an invoice is posted for a prepaid service, revenue is always automatically posted to a deferral account instead of a revenue account. This applies to both one-time and recurring prepaid services (via [Customer Subscription Contracts](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/working-with-contracts/customer-contracts)). The deferred amounts are later transferred to a revenue account when the related consumption is posted. The accounts used are determined by the posting setup matrix. ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported languages **DYCE Prepaid Services** is available in English and German. --- ## DYCE Record History & Favorites # Welcome to DYCE Record History & Favorites With this DYCE app, all records can be saved as **Favorites**. This way, you can access recently used entries with just one click. Want to save time when working with Microsoft Dynamics 365 Business Central? **DYCE Record History & Favorites** makes it possible. ![](/img/2021-02-23-09-53-13.png) ## Save favorites and save time with the DYCE App ERP systems combine numerous functions. Navigation here can be very time-consuming. Selecting and opening a customer card, a sales offer or something similar takes an average of ten seconds. If you have to repeat this process several times and regularly, seconds quickly turn into minutes, maybe even hours. If you can't find a record directly, this action takes even more time. Use **DYCE Record History & Favorites** and stop wasting time navigating Dynamics 365 Business Central. The display is clear and you can access all records with just a few clicks. This way you work faster and more efficiently. Open the record you were working on with just one click. This DYCE application consists of two parts: Role Center module **Last Records** stores your records in chronological order after they are opened. **Favorites**, on the other hand, is used to store a list of bookmarks or shortcuts that contain the records you use most often. ## Features of Record History & Favorites * Chronological display of records you use regularly * Time-saving display allows effortless access to recently opened records * Saving records as favorites directly in the Role Center of Microsoft Dynamics 365 Business Central * Simultaneous deletion of records from all lists ## Supported Editions Premium and Essential edition of Dynamics 365 Business Central. ## Supported Countries All countries supported by Dynamics 365 Business Central. ## Supported Languages **DYCE Record History & Favorites** is available in English, French, German and Serbian. --- ## DYCE Subscription & Recurring Billing # Welcome to DYCE Subscription & Recurring Billing :::warning Attention: End-of-life 30.06.2026 Please note that **DYCE Subscription & Recurring Billing** will be discontinued on 30.06.2026! All functionalities have been transferred to Business Central Standard as part of **Microsoft Subscription Billing**. For the changeover and data migration, please refer to [these notes](/docs/srb/srb-sb.md). ::: The **DYCE Subscription & Recurring Billing** app enables you to bill for contractually agreed Service Commitments on a recurring basis. The integrated flexible billing models support you and also take into account terms and notice periods. Do you want to create accurate invoices for different price and subscription models in just a few steps? At the same time, do you want to minimize sources of error and bring transparency into the processes? All this is possible with **DYCE Subscription & Recurring Billing**. ## Flexible and user-friendly subscription management for Business Central Every Service Object, whether it is a Sales Order, a rental agreement or any other contractual agreement between two parties, can be clearly assigned to customers. While the Service Object is usually static, the associated Service Commitments can change. Various billing information, such as billing period and amount, is usually stored with the individual Service Commitments in ERP systems, but not with the Service Object itself. If you use **DYCE Subscription & Recurring Billing**, all relevant information can be combined in one system. This allows you to maintain an overview of contract management at all times. At the same time, your manual effort is reduced, as processes can be significantly simplified and automated. With our contract management system, you can effectively handle all steps - from the offer to monthly billing - for both sides. ## Features of Subscription & Recurring Billing * Creation of individual and automated billing periods * Combining individual components into a product Bundle * Preview all existing monthly recurring billing and your upcoming invoices * Simplify billing with Billing Templates * Automatic calculation of notice periods * Accrual-based posting of income and expenses to profit and loss accounts ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported Languages **DYCE Subscription & Recurring Billing** is available in English and German. --- ## DYCE Smart Workflow Tool # Welcome to DYCE Smart Workflow Tool With **DYCE Smart Workflow Tool**, users can categorize documents by assigning a workflow and setting a status based on that workflow. Both the workflow and the status can be used for filtering and grouping. A specific document can be forwarded to another team or department by setting a corresponding status, which this team then filters on. Setting a specific status can also trigger an action, such as releasing the document. In addition, a flow can be started using [integration with Power Automate](/docs/swt/setup.md#business-events-and-external-systems). ## Collaboration with DYCE Cockpit Collaboration with **[DYCE Cockpit](/docs/cp/welcome.md)** enables the combined use of workflows and the clustering of documents on the one hand and the display of documents with the corresponding status in the user's personal Role Center on the other. ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported languages **DYCE Smart Workflow Tool** is available in English and German. --- ## DYCE Usage Based Billing # Welcome to DYCE Usage Based Billing :::warning Attention: End-of-life 30.06.2026 Please note that **DYCE Usage Based Billing** will be discontinued on 30.06.2026! All functionalities have been transferred to Business Central Standard as part of **Microsoft Subscription Billing**. For the changeover and data migration, please refer to [these notes](/docs/srb/srb-sb.md). ::: The demand-based provision of services requires a high degree of flexibility in both the creation and billing of Services. Thanks to the automated usage data import of **DYCE Usage Based Billing**, all steps - from the import of billing data to invoicing - are combined in one interface. Would you like to organize your services on the basis of suitable contracts? **DYCE Usage Based Billing** provides the solution. Since the provision of services is usually associated with a duration, the term *subscription* is often used in this context. Depending on the pricing model, a monthly basic fee plus a usage-dependent fee (e.g. per user, per transaction, etc.) can be charged for use. In addition, prices can often also vary depending on the quantity (graduated prices). ## Importing and processing usage data through Usage Based Billing If your company offers certain services on demand, it can be time-consuming to bill these individually. Often information is missing or the billing is confusing. **DYCE Usage Based Billing** extends the functionality of **[DYCE Subscription & Recurring Billing](/docs/srb/welcome.md)**. It allows you to seamlessly import usage data from various vendors into the ERP system. The data is then processed and proper prices are calculated. Using existing or available contracts, you can then create suitable invoices with just a few clicks. If you wish, you can also display a detailed overview of all items on the invoices. This is then also visible on the print version of the invoice. In the first expansion stage, the module offers a *generic* import and can therefore be used individually and independent of suppliers. ## Features of Usage Based Billing * Import of usage data from different suppliers via reconciliation files or web services * Daily accurate billing even for quantity changes and partial periods * Billing proposals with details for all services to be billed in a single overview * Contract invoices include an overview of billing details * Contract credits and refunds ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported Languages **DYCE Usage Based Billing** is available in English and German. --- ## DYCE Project & Resource Planning # Welcome to DYCE Project & Resource Planning DYCE Project & Resource Planning enables the creation of detailed project plans and the effective allocation of resources. It ensures optimal management of employee capacities and skills throughout the project lifecycle. It addresses two variants of planning, high-level, capacity based planning (project plans) and detailed planning for short lived tasks (work orders). It is designed to help businesses manage their projects more efficiently by providing tools for planning, scheduling, and tracking project progress. It does this by answering these fundamental questions: * *When* can we start this new project and which resources with a certain skill are available? * When the project is on its way, how is the progress? Are you even making progress and what does the budget look like? * What are the tasks and dependencies between the tasks? * How long will the project take to be completed? * When will a team have capacities to take on another project? * What tasks are not yet assigned to a resource? Does a resource have time to take on this task on a specific date? ## Features of DYCE Project & Resource Planning * Project plan with tasks and dependencies * Resource and placeholder planning * Capacity and skills management * Budget management * Time recording (in combination with **[DYCE Time Tracking](/docs/web/tt/welcome.md)**) ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported Languages **DYCE Project & Resource Planning** is available in English and German. --- ## DYCE Time Tracking # Welcome to DYCE Time Tracking The time tracking software **DYCE Time Tracking** enables you to bill services in an uncomplicated and fast way. In combination with **[DYCE Project Billing](/docs/pb/welcome.md)** you can report, release and invoice billable times directly in Business Central. You are looking for a user interface that impresses with clarity and thus minimizes possible errors at the same time? Then **DYCE Time Tracking** is the perfect extension for you and your company. ## Billing services with time recording from DYCE **DYCE Time Tracking** is a web-based time recording app for Microsoft Dynamics 365 Business Central. Using this DYCE app allows you to intuitively record all services, correct them if necessary and then release them. Users can keep track of their time recordings with the state-of-the-art dashboard. The time recording software is easy to understand, which significantly reduces the training effort for employees. The large number of templates makes reporting even easier. If a job is to be invoiced, all entries are displayed in an overview and variable or missing values are highlighted. These can then be directly adjusted and completed with the invoicing. **DYCE Time Tracking** is integrated into **DYCE Project Billing** app, which is required for invoicing and full functionality. This combination package for Business Central provides reliable quick entry with efficient workflow. ## Part of DYCE Connect **DYCE Time Tracking** is part of the **[DYCE Connect Platform](/docs/web/introduction.md)**. After logging in at https://app.dyce.cloud/, three areas are basically available: * Administration * Time Tracking * Planning Which areas are displayed here are also depending on the role assigned to the logged in user. Clicking on the *Time Tracking* button leads to the first page: the **[Dashboard](/docs/web/tt/time-tracking/dashboard.md)**. ## Features of DYCE Time Tracking * Intuitive documentation in Business Central through the combination of **DYCE Time Tracking** and **DYCE Project Billing** * Fast time recording through customizable templates * Free choice between light and dark mode * Less training effort thanks to intuitive user interface * Overview of target/actual times facilitates correct recording of all jobs * Create time recordings based on Outlook appointments ## Supported versions This app supports both the Essential and Premium editions of Microsoft Dynamics 365 Business Central. ## Supported countries Users worldwide can use this application. ## Supported Languages **DYCE Time Tracking** is available in English and German. --- ## DYCE docs # Welcome to DYCE documentation **DYCE** stands for **Dynamic Cloud Experience**. With our sophisticated extensions for **Microsoft Dynamics 365 Business Central** you control all business processes efficiently and time-saving. DYCE powered by Singhammer offers the latest technologies for your processes and your workflow. On this page you will find all the most important information about our apps for **Business Central**. The menu in the navigation area will take you to the pages of the individual applications. In addition to introductory explanations, you will find the individual app functions listed and explained in detail. Updates and changes are each recorded in the **Changelog** sections and in the **[Release Notes](/blog)**. --- ## About this part This general part of the DYCE documentation contains information that applies to all DYCE apps. Usually, these are functionalities that are provided via the so-called library app **[DYCE Essentials](/docs/general/essentials/welcome.md)**. **DYCE Essentials** is included with several DYCE apps. For more information, see [here](/docs/general/essentials/activation.md). --- ## Activation **DYCE Essentials** is included in the DYCE app suites and apps listed below. The use is free of charge. Consequently, there is no billing. Also, no activation is required for use. Overview of the app suites in which **DYCE Essentials** is included: * **[DYCE Professional Services Suite](/docs/appsuites/pss.md)** * **[DYCE Professional Services Suite Pro](/docs/appsuites/pss-pro.md)** * **[DYCE Business Suite](/docs/appsuites/bs.md)** * **[DYCE for IT Resellers](/docs/appsuites/itrs.md)** * **[DYCE Feature Suite for Subscription Billing](/docs/appsuites/fssb.md)** Furthermore, **DYCE Essentials** is also included in the standalone app**[DYCE Project Billing](/docs/appsuites/standalone/pb.md). --- ## Adjust Posting Dates When a purchase or sales document is created, the dates are set based on the workdate. However, if, for example, a sales order is not posted (invoiced) until a later date, these dates are not updated automatically. This must be done manually before posting. To improve real-life sales and purchase posting scenarios, **DYCE** allows users to adjust the **Posting Date**, **Document Date** and **VAT Date** during posting, eliminating the need to change the original document beforehand. The **Adjust Dates on Posting** field on the **General Ledger Setup** page controls whether users can change the **Posting**, **Document**, and **VAT Date** during sales or purchase posting. If enabled, an extended dialog with dates fields appears when posting *sales* or *purchase* documents. This functionality is aligned with standard Business Central behavior, including the **VAT Date Usage** setting in the **General Ledger Setup**, where the **VAT Date** field is shown in the dialog only if the setting is set to *Enabled* or *Enabled (Prevent Modif.)*. It also respects the **Invoice Posting Policy** for sales and purchase documents which are defined, among others, in the **User Setup**. --- ## Batch Sending Documents **Document Sending Profiles** can be used to determine how e.g. customers receive their invoices and credit memos. The user can define different Document Sending Profiles and assign the appropriate profile to each customer. For more details, please refer to this part of the Microsoft documentation. When sending posted Sales invoices and credit memos, the Document Sending Profile that is stored with the related invoice recipient (customer) is used. With DYCE, the Document Sending Profile is additionally displayed as a criterion for filtering the posted Sales documents in the document itself. In addition, the standard dialog that queries the required parameters for sending can be suppressed and the settings imposed on the customer can be used instead. The **Batch Sending Documents** field in the **Sales & Receivables Setup** is used for this purpose. To batch send posted Sales documents, the user selects the appropriate documents and - depending on the setup - can also batch send. --- ## Create Item(s) # Create items The **Create item(s)** action is used to create items from Catalog Items via batch. The action is located in the **Home** menu on the page **Catalog Items**. When executed, items are created for all selected Catalog Items. To ensure that the action can be executed without errors, at least the following fields must be filled in the Catalog Item: * Vendor No. * Vendor Item No. * Item Template Code If these fields are not filled, the execution of the batch is interrupted and no item is created. In essence, if for one of the selected Catalog Items an entry is missing in one of the three fields, no item will not be created for any of the selected Catalog Items. --- ## Customer Dimension # Dimension for Customers In **Sales & Receivables Setup** page the field **Autom. Insert Customer Dimension Value** controls whether the **Customer No.** is automatically created as a new dimension value for each new customer. This is then automatically assigned to the respective customer. Dimensions are usually used for evaluation purposes and are passed on from the master record (here: customer) to the associated transaction data. For details on how dimensions work, please refer to this part of the Microsoft documentation. The default value for this setting is *YES*. --- ## Position Numbers # Numbering for positions in Sales documents Position numbers are available in the *Sales Quotes*, *Sales Orders*, *Sales Invoices* and *Sales Credit Memos*. They improve the clarity of the document in the printout. The position numbers are assigned automatically. For example, a [Bundle](/docs/ebs/bundles.md) as a whole has a position number, the components have none. The position numbers can be reassigned automatically using the **Compute Position Nos.** action (in the line menu via *Manage*) or alternatively overwritten manually. --- ## Print Preview # Print Preview for Sales documents In Business Central, in documents that have not yet been posted, the **Preview Posting** action provides the option to preview the ledger entries that will be created when the document is posted. This functionality has been extended in DYCE for Sales invoices and Sales credit memos, so that a *print preview* of the posted document is also available. This functionality can be accessed via the **Invoice Preview** or **Credit Memo Preview** action (in the respective document via the *Post* menu). --- ## Report Configuration # Report Configurations The **Report Configurations** can be used to make general settings that apply to all DYCE report layouts. These primarily relate to the position of the logo (**Logo Position**) and the footer. The contents for the footer can be stored for different language codes so that reports in foreign languages also output the correct contents. Several configurations can be created, which can be provided with a validity (field **Valid From**). The image shown in the logo position is stored in the **Logo** field. If it is left empty (and **Logo Position** is not set to *No Logo*), the picture stored in **Company Information** is used automatically as a fallback. Setting **Logo Position** to *No Logo* suppresses the logo entirely, even if a Company Information picture exists. The logo is rendered at the same size and position across all RDL and WORD report layouts and in the **Report Configuration Preview**; for technical background on how RDL renders images differently from WORD, see [Report Extensions & Layouts](/docs/general/essentials/report-extensions-layouts.md). The footer itself is divided into six areas, each of which can output its own content. The content can be created or modified either by clicking in one of the fields **Footer Column 1-6** or by calling the corresponding action **Edit Footer Column 1-6**. A window opens in which multiline text can be entered. The font size for the output is specified via the **Footer Font Size (pt)** field. For multi-page reports, the heading for subsequent pages can be specified via the **Caption Page No.** field. :::tip Tip To adjust the horizontal alignment of the footer's content, leading spaces can also be used in the content windows. ::: For illustration purposes, the result of the configuration can be checked directly via the **Preview** action. --- ## Report Extensions & Layouts # Extensions to reports and layouts To enable the content of the DYCE Apps to be output via the print documents, **DYCE Essentials** includes enhancements to the dataset of the following standard reports, among others: * **Purchase** * Purchase Order * Blanket Purchase Order * **Sales** * Quote * Order Confirmation * Blanket Order * Shipment * Invoice (incl. details of services invoiced) * Credit Memo * Reminder Furthermore, two additional report layouts for WORD and for RDL are supplied for each report. These can be identified by the extension name **DYCE Essentials**. The additional layouts are basically based on the standard layouts for the respective reports, but are extended with regard to the content created via the DYCE apps. It is possible to use them out-of-the-box. Alternatively, it is possible to copy and modify the layouts and use them as customer-specific layouts. :::info Images in RDL layouts Images in the RDL layouts must be flattened onto their background colour - no alpha channel. The Reporting Services PDF renderer that Business Central uses for RDL stores every non-JPEG image as BMP, which has no alpha, so transparency is discarded while the RGB is kept: semi-transparent and fully transparent pixels print at full colour saturation. Word layouts convert via a different component that writes a PDF soft mask, which is why the same logo is correct there. Not configurable - the image report item has no opacity property. This applies to all RDL layouts in Business Central, not just DYCE. ::: --- ## Setup # Setup of DYCE Essentials **DYCE Essentials** does not necessarily require any special setup. However, setup for the topics [Customer Dimension](/docs/general/essentials/customer-dimension.md), [Batch Sending Documents](/docs/general/essentials/batch-sending-documents.md) and [Report Configurations](/docs/general/essentials/report-configuration.md) are possible. These are explained in the respective sections. ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCEESSENTIALSALL (DYCE Essentials Read)** This permission set can be assigned to all users. It includes read-only permissions to use the components of **DYCE Essentials**. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCEESSENTIALSUSER (DYCE Essentials User)** This permission set is for all users who should be able to print and work with documents. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCEESSENTIALSADMIN (DYCE Essentials Admin)** This permission set is designed for administrators and power users who should additionally be able to make adjustments to Report Configurations. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information on permission sets, see this part of the Microsoft documentation. --- ## DYCE Broker The **DYCE Broker** app is a free, so-called *library* app that is automatically installed with all DYCE apps. It enables communication between DYCE apps that are not dependent on each other by implementing a loose binding - without type checking during compilation, only during runtime. It is purely a technical necessity that can also be used for development purposes. :::danger Uninstalling DYCE Broker If the **DYCE Broker** app is uninstalled, **all DYCE apps** are also uninstalled automatically. This can lead to unintentional data loss. ::: --- ## Business Suite # DYCE Business Suite The **DYCE Business Suite** is a compilation of apps in Microsoft Dynamics 365 Business Central that are primarily geared towards the needs of the IT industry, but go far beyond this. It addresses the typical requirements of (IT) trading companies, system houses and software manufacturers - from quotation and order processes, document and workflow control to the import of complex price lists and the handling of payment plans. The suite extends the Business Central standard in key areas and enables, for example, the automatic linking of sales orders and purchase orders, the import of supplier configurations directly into quotations and working with margin calculations. The suite is available for purchase as a bundle only. Please follow the links below for more information on the components. The bundle consists of the following apps: * **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** - Functionality for IT retail business, including order-related procurement, payment plans, calculation import, margin calculation * **[DYCE Smart Workflow Tool](/docs/swt/welcome.md)** - Status and workflow control for documents; filtering by process status and integration into Power Automate; interaction with **DYCE Cockpit** * **[DYCE Price List Import](/docs/pli/welcome.md)** - Import and maintenance of complex supplier price lists, including history and filters; reduces manual effort * **[DYCE Cockpit](/docs/cp/welcome.md)** - Configurable cues for tasks and priorities in the Role Center * **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** - Combining several products into a package deal; controlling which information appears on the customer side * **[DYCE Happy Texts](/docs/ht/welcome.md)** - Formattable long texts, greetings/postscripts, and images in documents; templates for professional documents * **[DYCE Document Tracker](/docs/dt/welcome.md)** - Keep track of document links between sales and purchasing; quick access to related processes * **[DYCE Record History & Favorites](/docs/rhf/welcome.md)** - Quick access to recently opened or favorite records, directly in the role center * **[DYCE Essentials](/docs/general/essentials/welcome.md)** - Position numbers in sales documents, print preview of sales documents not yet posted, report configuration Further information and prices can be found on the related website. ## Core benefits at a glance * **Process clarity in sales & purchasing** Automatic linking of sales order and Purchase Order, document links visible in **DYCE Document Tracker**, central task overview in **DYCE Cockpit**. * **Fast quotation creation from supplier configurations** Import calculations (CSV or interface) incl. automatic item/catalog item creation, marking of main components/texts and optional special bid specification. * **Payment Plans & Down Payments** Milestone and prepayment logic in sales documents with separate number ranges for prepayment documents. * **Margin calculation instead of fixed sales prices** Optional trade margin or calculation surcharge as basis for calculation directly in the sales line * **Work saving and clean communication** **DYCE Happy Texts** for formatted long texts, pre/post texts and images; **DYCE Easy Bundle Seller** for a simplified external offer structure. * **Keep price lists up to date** Import/update complex supplier price lists including historical comparability and flexible filters. ## Most important features of the Business Suite * **Import calculations** Import from CSV file via data exchange definition; DYCE provides a template that can be customized for each supplier. Automatic recognition of main/component/text lines; use of manufacturer item numbers to reference existing catalog items and automatically create missing ones. * **Payment plans & advance payments** Easily create flexible advance payments, number series for booked advance payment receipts. Mapping milestone invoices, partial/final invoices, and booking logic for unrealized VAT. * **Margin calculation** Trade margin and calculation surcharge in percent directly in sales lines; dynamic calculation including contribution margin (MW). * **Order-related procurement & document links** Create purchase orders from sales documents incl. reservations and display the links via **DYCE Document Tracker**. * **Price list import** Multiple supplier prices per item, flexible filters during import, historization for comparisons. * **Productivity & Communication** **DYCE Happy Texts**: formattable long texts, images, templates; **DYCE Cockpit**: configurable cues; **DYCE Smart Workflow Tool**: status control + Power Automate; **DYCE Record History & Favorites**: quick access ### Overview of all features |Area|Feature|Description| |:--|:--|:--| |Import calculations|Import calculations or manufacturer quotations|Import calculation data (e.g. CSV files, XML etc.) as quotation lines in sales documents| |Import calculations|Transformation rules and mapping|Configure transformation rules, fixed values and field mapping for the import| |Import calculations|Interface for import|Import also possible via API| |Import calculations|Easy import of items that are not yet stored in BC|Items that have not yet been entered in BC can be imported and automatically processed in the background| |Import calculations|Create quotation/order lines|Imported data creates quotation or order lines| |Process + status|Automatic release|Automatically release sales and purchasing documents based on a status| |Process + status|Workflows & Statuses|Assign individual statuses to multi-level document processes in sales and purchasing| |Process + status|Workflows in subscription contracts|Processes in subscription contracts with individual statuses| |Process + status|Document categorization|Processes/status as categorization for various sales and purchasing processes| |Process + status|Status-controlled actions|Status change triggers actions such as workflows, reports or code units| |Process + status|Status history|Logs user, date and status change| |Process + status|Process cycles|Status steps can be repeated by jumping back| |Process + status|Integration Power Automate|Status change can trigger business events/flows. Status can be set via flows outside of BC (e.g. Teams messages)| |Process + status|Setup via templates|Processes can be configured easily and individually via templates| |Calculate sales margin|Calculate percentage sales margin|Calculate sales price via sales margin to calculate purchase price| |Calculate sales margin|Calculate percentage mark-up|Calculate sales price via mark-up to cost price| |Calculate sales margin|Display margin & contribution margin|Dynamic display of margin % and contribution margin in the sales document line| |Calculate Sales Margin|Actual Unit Cost per Sale|The actual Unit Cost from a Purchase Order is assigned to the correct sales thanks to an order-related Purchase Order| |Calculate sales margin|Evaluation of the correct contribution margin via posted sales invoice and credit memo|Regulated Unit Costs are also updated in posted sales invoices and credit memos| |Design sales documents|Creating product Bundles|Combining several products or Services into one package| |Design sales documents|Predefined product bundles via item master data|Frequently used product bundles can be created as a separate item so that they can be used easily and recurrently| |Design sales documents|Automatic price calculation and adjustment|Automatic calculation of the Bundle price from the individual prices as a proposal that can be adjusted| |Design sales documents|Bundles in subscription invoices|Group subscription contract lines into Bundles and customize formatting| |Design sales documents|Distribute discounts|Distribute discounts to Bundle components as desired| |Design sales documents|Bundle prices|Define a Bundle price that is distributed proportionally to the components| |Design sales documents|Format Bundles as desired|Control visibility/highlighting of Bundles and components| |Design sales documents|Subtotals|Freely definable subtotals in the sales documents| |Design sales documents|WORD and RDL layouts|Attractive Word and RDL layouts| |Design Sales Documents|Automatic Position Numbers|Automatic Position Numbers in Sales Documents| |Design sales documents|Configuring the footer|Setting up the footer depending on validity date and language| |Design sales documents|Configure logo position|Set up logo position left, center or right| |Design sales documents|Advanced description in sales documents|Unlimited and formattable texts in sales documents| |Design sales documents|Advanced description in contracts|Unlimited and formattable article texts in Customer subscription contracts| |Design sales documents|Personal salutations & farewells|Individual greetings and closing texts in sales documents| |Design sales documents|Images in texts|Embedding images in texts| |Design sales documents|Editor add-in|Editor with paragraphs, lists, font formatting| |Design sales documents|Automatic integration in sales processes|Automatically insert texts in offers, orders, items| |Design sales documents|Text templates|Default templates can be defined and used automatically| |Design sales documents|CSS setup|Standard formatting customizable via CSS template| |Manage Payment Plans|Create Payment Plans|Use your own (partial) payment plans with multiple stages in the sales order| |Manage Payment Plans|Create Prepayment Invoice|Create a Prepayment Invoice based on a Payment Plan| |Manage Payment Plans|Multi-level payment steps|Store payment plans with fixed totals or percentages| |Manage Payment Plans|Distribution based on items|Distribute prepaid amount to single or multiple items| |Manage Payment Plans|Additional fields per payment stage|Description, planned invoice date, payment terms, etc.| |Manage Payment Plans|Invoicing step by step|Settle individual Payment Plan Steps| |Manage Payment Plans|Create prepayment invoice as unposted invoice|Create payment and prepayment invoice as unposted invoice (do not post immediately)| |Manage Payment Plans|Warning Open Prepayments|Warning Open Prepayment Invoices| |Manage licensees|Store licensee obligation in the article master|In the article master you can specify that licensees are required in sales| |Manage licensees|Display missing mandatory data|Unlink the sales process if necessary licensee data is missing| |Manage licensees|Transfer licensee to purchase order|The licensee data from the sales order is automatically transferred to the associated purchase order from the supplier| |Manage licensees|Transfer licensee to subscriptions|Licensee data is transferred to related subscriptions created from the order| |Find information|Up to 24 individually definable tiles in Role Center|Display important processes, to-dos and data as tiles in the Role Center individually tailored to the individual user| |Find information|Quick access to related documents|Displays all related documents for a process| |Find information|Access via document card & search|App can be called up directly from the document card or search| |Find information|Fixed predefined tiles on BC start page (Role Center)|Fixed tiles for certain processes in the Role Center ("BC Role Center")| |Find information|Colored limit value visualization|Tiles can be highlighted in color when individually defined limits are exceeded| |Find information|Filter templates|Templates with table, page, filter criteria, date, threshold values freely definable| |Find information|Display of invoice recipient and supplier|Customer and Vendor are displayed directly in the contact list and contact card| |Find information|Sales history fact box in Customers|Displays all transactions as sales recipients| |Find information|Sales history in contacts fact box|Displays all transactions as sales recipients| |Find information|Display last records in Role Center|Displays the last accessed data in Role Center| |Find Information|Favorites in Role Center|Mark individual records as favorites and display and access them in the Role Center| |Purchasing general|Create Purchase Order|Direct creation of a Purchase Order from the sales order| |Purchasing general|Reservation on Purchase Order|Direct reservation in Purchasing to assign an ordered item to a specific sales order| |Purchasing general|Save vendor in item|A Vendor can be saved as a vendor in the item| |Purchasing general|Favorite suppliers|Select a favorite for each item if there are several suppliers| |Purchasing general|Import supplier price lists|Import differently formatted price lists for catalog items| |Purchasing general|Use import templates|Save templates with field mapping| |Purchasing general|Automatic update of purchase prices for existing items|Update purchase prices from different suppliers on existing items and catalog items| |Purchasing general|History price development|Overview of the price development of the respective items| |Purchasing general|Articles from catalog data|Convert catalog items to articles in the offer| |Purchasing in the IT industry|Special bid prices|Special agreements (so-called special bids) can be imported directly. The number can be displayed and thus used in sales and purchasing| |Purchasing in the IT industry|Summary by Special Bid|Summarize Purchase Orders by Special Bid No.| |Purchasing in the IT industry|Create items from catalog in batch|Convert multiple catalog items in batch to items| --- ## Feature Suite for Subscription Billing # DYCE Feature Suite for Subscription Billing The **DYCE Feature Suite for Subscription Billing** extends the possibilities of **Microsoft Subscription Billing** in Dynamics 365 Business Central. It supplements the standard with tiered prices, additional usability features and makes it easier to work with complex billing models for recurring subscriptions. This package is aimed at all companies that want to optimize their subscription billing processes and add flexible pricing. The suite is available for purchase as a bundle only. Please follow the links below for more information on the components. The bundle consists of the following apps: * **[DYCE Feature Suite for Subscription Billing](/docs/fssb/welcome.md)** - Extensions for Microsoft Subscription Billing, incl. tiered prices and convenience functions * **[DYCE Price List Import](/docs/pli/welcome.md)** - Import and maintenance of complex supplier price lists, including history and filters; reduces manual effort * **[DYCE Cockpit](/docs/cp/welcome.md)** - Configurable cues for tasks and priorities in the Role Center * **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** - Combining several products into a package deal; controlling which information appears on the customer side * **[DYCE Happy Texts](/docs/ht/welcome.md)** - Formattable long texts, greetings/postscripts, and images in documents; templates for professional documents * **[DYCE Record History & Favorites](/docs/rhf/welcome.md)** - Quick access to recently opened or favorite records, directly in the role center * **[DYCE Essentials](/docs/general/essentials/welcome.md)** - Position numbers in sales documents, print preview of sales documents not yet posted, report configuration Further information and prices can be found on the related website. ## Core benefits at a glance * **Advanced pricing** Simple and detailed tiered pricing for subscriptions and recurring subscriptions. * **Optimized usability** Convenient functions, such as the pre-assignment of subscriptions to contracts, for day-to-day work with Microsoft Subscription Billing. * **Seamless integration** Direct extension of Microsoft Subscription Billing. * **Keep price lists up to date** Import/update complex supplier price lists including historical comparability and flexible filters. * **Time saving and clean communication** **DYCE Happy Texts** for formatted long texts, pre/post texts and images; **DYCE Easy Bundle Seller** for a simplified external offer structure. * **Productivity at a glance** **DYCE Cockpit** for configurable cues; **DYCE Record History & Favorites** for quick access and tracking. ## Most important features of the Feature Suite for Subscription Billing * **Tier pricing for subscriptions** Flexible pricing based on quantities or usage as flat or detailed tiered pricing; Automatic calculation and display in the sales process. * **Usability features and integration** Improved user guidance and additional options in Microsoft Subscription Billing. * **Price list import** Multiple supplier prices per item, flexible filters during import, historization for comparisons. * **Productivity & Communication** **DYCE Happy Texts**: formattable long texts, images, templates; **DYCE Cockpit**: configurable cues; **DYCE Record History & Favorites**: quick access ### Overview of all features |Area|Feature|Description| |:--|:--|:--| |Tier prices|Maintain standardized tier prices as package prices|Enter standardized tier prices on the item| |Tier prices|Maintain detailed tier prices as package prices|Enter detailed tier prices on the item| |Tier prices|Scale price calculation in sales documents|Consideration of tier prices in the price calculation in the sales line| |Tier prices|Scale price calculation in sales documents with additional quantity|Consideration of a subscription or an additional quantity in the scale price calculation in the sales line| |Tier prices|Scale price calculation in subscriptions and subscription contracts|Consideration of tier prices in the price calculation in subscriptions and subscription contracts| |Tier prices|Scale price calculation for usage data|Consideration of tier prices in the price calculation for quantity-based usage data| |Usage data|Inclusive quantities for usage data|Mapping of inclusive quantities and additional calculation of excess consumption| |Usage data|[Automatic quantity adjustment for usage data Bundles](/docs/fssb/usage-data-bundles.md)|A quantity change of the usage-based component changes the quantities of the other components and of the Bundle| |Usability|Assign contract|Assign target subscription contract already in the sales line| |Design sales documents|Create product Bundles|Combine multiple products or Services into one package| |Design sales documents|Predefined product bundles via item master data|Frequently used product bundles can be created as a separate item so that they can be used easily and recurrently| |Design sales documents|Automatic price calculation and adjustment|Automatic calculation of the Bundle price from the individual prices as a proposal that can be adjusted| |Design sales documents|Bundles in subscription invoices|Group subscription contract lines into Bundles and customize formatting| |Design sales documents|Distribute discounts|Distribute discounts to Bundle components as desired| |Design sales documents|Bundle prices|Define a Bundle price that is distributed proportionally to the components| |Design sales documents|Format Bundles as desired|Control visibility/highlighting of Bundles and components| |Design sales documents|Subtotals|Freely definable subtotals in the sales documents| |Design sales documents|WORD and RDL layouts|Attractive Word and RDL layouts| |Designing Sales Documents|Automatic Position Numbers|Automatic Position Numbers in Sales Documents| |Designing sales documents|Configuring the footer|Setting up the footer depending on validity date and language| |Design sales documents|Configure logo position|Set up logo position left, center or right| |Design sales documents|Advanced description in sales documents|Unlimited and formattable texts in sales documents| |Design sales documents|Advanced description in contracts|Unlimited and formattable article texts in customer subscription contracts| |Design sales documents|Personalized salutations & farewells|Individualized greetings and closing texts in sales documents| |Designing sales documents|Images in texts|Embedding images in texts| |Design sales documents|Editor add-in|Editor with paragraphs, lists, font formatting| |Design sales documents|Automatic integration into sales processes|Automatically insert texts in offers, orders, items| |Design sales documents|Text templates|Default templates can be defined and used automatically| |Design sales documents|CSS setup|Standard formatting customizable via CSS template| |Purchasing general|Import supplier price lists|Import differently formatted price lists for catalog items| |Purchasing general|Use import templates|Save templates with field mapping. |Purchasing general|Automatic update of purchase prices for existing items|Update purchase prices from different suppliers on existing items and catalog items| |Purchasing general|History price development|Overview of the price development of the respective items| |Purchasing general|Items from catalog data|Convert catalog items to items in the offer| |Purchasing in IT industry|Create items from catalog in batch|Convert multiple catalog items in batch to items| --- ## IT Resellers Suite # DYCE for IT Resellers **DYCE for IT Resellers** is the complete package for system houses and managed service providers who want to efficiently map their commercial business. It combines the proven functions of the **[DYCE Business Suite](/docs/appsuites/bs.md)** with additional features for the management of subscription contracts and recurring services. This package supports you with quotation and order processing, price list management, workflow control and extends the range of functions with specific tools for managed services. The suite is available for purchase as a bundle only. Please follow the links below for more information on the components. The bundle consists of the following apps: * **[DYCE Managed Service Providers](/docs/msp/welcome.md)** - Extensions for mapping special functions for managed services and integrating subscription contracts. * **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** - Functionality for IT retail business, including order-related procurement, payment plans, calculation import, margin calculation * **[DYCE Smart Workflow Tool](/docs/swt/welcome.md)** - Status and workflow control for documents; filtering by process status and integration into Power Automate; interaction with **DYCE Cockpit** * **[DYCE Price List Import](/docs/pli/welcome.md)** - Import and maintenance of complex supplier price lists, including history and filters; reduces manual effort * **[DYCE Cockpit](/docs/cp/welcome.md)** - Configurable cues for tasks and priorities in the Role Center * **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** - Combining several products into a package deal; controlling which information appears on the customer side * **[DYCE Happy Texts](/docs/ht/welcome.md)** - Formattable long texts, greetings/postscripts, and images in documents; templates for professional documents * **[DYCE Document Tracker](/docs/dt/welcome.md)** - Keep track of document links between sales and purchasing; quick access to related processes * **[DYCE Record History & Favorites](/docs/rhf/welcome.md)** - Quick access to recently opened or favorite records, directly in the role center * **[DYCE Essentials](/docs/general/essentials/welcome.md)** - Position numbers in sales documents, print preview of sales documents not yet posted, report configuration Further information and prices can be found on the related website. ## Core benefits and most important features at a glance In addition to the functions of the **[DYCE Business Suite](/docs/appsuites/bs.md)**, **DYCE for IT Resellers** brings added value consisting of: * **Partial shipments from sales orders** Multiple warehouse shipments per order instead of just one - flexible splitting of items and quantities. * **Purchasing according to requirements** Purchase orders can be made on the basis of planned partial shipments, not for the entire quantity. * **Different delivery addresses** Different delivery addresses possible before and after creation of warehouse shipments. * **Automatic reservation** Stock is automatically reserved at warehouse shipments, adjustments possible before creation. * **Central order overview** New page **Purchase Requisition** summarizes all items to be ordered and enables collective orders. ### Overview of all features |Area|Feature|Description| |:--|:--|:--| |Delivery management|Control whether a Warehouse Shipments is required|You can define for each Locations whether a Warehouse Shipments is required or whether the possibilities of the Business Central Standard without Warehouse Shipments are sufficient| |Delivery management|Partial deliveries to different delivery addresses|Sales orders can be delivered in partial quantities; Partial Warehouse Shipments possible to ship only certain items or to serve different delivery addresses from one order| |Delivery management|Automatic inventory management|Automatic reservation of available quantities when creating goods issues; The remaining quantities are proposed for Purchase Order| |Delivery management|Integration of Drop Shipments|Drop Shipments (Whse.) can be used in combination with Warehouse Shipments. Warehouse Shipments are automatically posted when the purchase order is posted| |Delivery management|Improved Drop Shipments|It is possible to change the quantity in purchasing despite a drop shipment. The change is transferred to Warehouse Shipments accordingly| |Delivery management|Purchase Requisition as a central overview|The Purchase Requisition provides a central overview for Purchasing as to which items need to be procured and thus offers the ideal data basis for centralized purchasing| |Purchase order management|Create or extend purchase orders|New purchase orders can be created or existing purchase orders extended on the basis of the Warehouse Shipment lines| |Purchase order management|Create Purchase Order related to Warehouse Shipments|A dedicated Purchase Order can be created for this Warehouse Shipments based on the Warehouse Shipments| |Purchase order management|Reservation on Purchase Order|The purchase order line is also reserved directly for the Warehouse Shipment line when using the Warehouse Shipment line| |Purchase order management|Selection of Vendors|When creating a Purchase Order, you can choose from a predefined selection of vendors| |Subscription extension|Fixed service term|Mapping of fixed service terms for subscriptions that must be explicitly renewed| |Subscription extension|Warranty extension|Management and sale of additional service commitments such as extended warranty, which are sold separately but are linked to the original sale| |Subscription extension|Selling add-ons to existing subscriptions|Selling add-ons to existing subscriptions and thus extending them| |Subscription extension|Subscription Renewal|Subscription Renewal is a special list view based on subscription lines that displays all relevant information required to track expiring lines and perform follow-up actions such as renewals| --- ## Professional Services Suite Pro # DYCE Professional Services Suite Pro The master class of project planning - directly in your DYCE Connect platform! With the **DYCE Professional Services Suite Pro** you can say goodbye to the planning chaos in your daily project business. Control everything - from strategic overview to detailed resource planning - in an end-to-end workflow that seamlessly connects your systems and is fully synchronized with Microsoft Dynamics 365 Business Central. The suite is available for purchase as a bundle only. Please follow the links below for more information on the components. The bundle consists of the following apps: * **[DYCE Project & Resource Planning](/docs/web/prp/welcome.md)** - Resource and capacity planning, incl. skills and placeholders * **[DYCE Project Billing](/docs/pb/welcome.md)** - Project-based invoicing, flexible billing models, surcharges for work outside standard working hours * **[DYCE Time Tracking](/docs/web/tt/welcome.md)** - Modern time recording for services, mobile and web-based * **[DYCE Prepaid Services](/docs/ps/welcome.md)** - Management of Prepaid Services, one-off and periodic billing * **[DYCE Cockpit](/docs/cp/welcome.md)** - Configurable cues for tasks & priorities in the Role Center * **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** - Compilation of several products into a package; control which information appears on the customer side * **[DYCE Happy Texts](/docs/ht/welcome.md)** - formattable long texts, greetings/after texts and images in documents; Defaults for professional documents * **[DYCE Record History & Favorites](/docs/rhf/welcome.md)** - Quick access to recently opened or favorite data records, directly in the Role Center * **[DYCE Essentials](/docs/general/essentials/welcome.md)** - Position numbers in sales documents, print preview of sales documents not yet posted, report configurations Further information and prices can be found on the related website. :::info Recurring Prepaid Services For reccuring Prepaid Services, integration with Microsoft Subscription Billing is used. ::: ## Core benefits at a glance * **Planning instead of documenting:** Structure projects before they start. * **Avoid bottlenecks:** Recognize early on who will be working on what in six weeks. * **Ensure growth:** Make decisions based on reliable data instead of gut feeling. * **Your advantage:** No Excel planning, no overload, full control over your pipeline. ## For whom is the Pro-Suite indispensable? The **DYCE Professional Services Suite Pro** is the ideal tool for companies whose success depends on precise resource management: * **Software Developers & Implementation Partners:** For complex, long-running projects. * **IT consulting & system houses:** For managing many parallel projects and service orders. * **MSPs with project business:** For an overview of tickets and consulting orders. * **Professional Services:** To reliably and profitably manage a growing project pipeline. ## Most important features of the Professional Services Suite Pro In addition to the features of **[DYCE Professional Services Suite](/docs/appsuites/pss.md)**, **DYCE Professional Services Suite Pro** brings added value consisting of: * **Project plan with tasks & dependencies** Structured planning including task relationships and time sequence. * **Resource & placeholder planning** Initially assign tasks to placeholders based on skills and later replace them with specific resources. * **Capacity & Skill management** Consider availability, workload and qualifications across teams and projects. * **Budget management** Allocate budgets to tasks; track progress and consumption transparently. * **Time Recordings on planned tasks** (in combination with **DYCE Time Tracking**) Actual effort automatically reduces the planned Budget and shows progress. * **Two planning variants** High-level, capacity-based project plans and detailed planning for short-lived work orders. ### Overview of all features |Area|Feature|Description| |:--|:--|:--| |Project & Resource Planning|Project plan with activities & tasks|Creation of a project structure with activities, tasks and dependencies| |Project & Resource Planning|Resource & Placeholder Planning|Assignment of specific persons/employees or placeholders in the project plan| |Project & Resource Planning|Capacity Management|Overview and monitoring of resource utilization| |Project & Resource Planning|Skill Management|Planning based on skills with different skill levels| |Project & Resource Planning|Budget Management|Control and evaluation of the project budget| |Project & Resource Planning|Time recording on planned tasks|Recording time directly for planned tasks (in combination with DYCE Time Tracking)| |Project & Resource Planning|Project progress display / budget reference|Display of progress and budget consumption| |Project & Resource Planning|Calendar / Planning View|Calendar display with absences (in combination with DYCE Time Tracking)| --- ## Professional Services Suite # DYCE Professional Services Suite The **DYCE Professional Services Suite** is the central package for companies that bill for services on a project basis. It supports you with project management, budgeting, time recordings, and the billing of professional services - including periodic prepayments and integration with Microsoft Subscription Billing. This suite provides you with powerful tools for all core processes in the project business. The suite is available for purchase as a bundle only. Please follow the links below for more information on the components. The bundle consists of the following apps: * **[DYCE Project Billing](/docs/pb/welcome.md)** - Project-based invoicing, flexible billing models, surcharges for work outside standard working hours * **[DYCE Time Tracking](/docs/web/tt/welcome.md)** - Modern time recording for services, mobile and web-based * **[DYCE Prepaid Services](/docs/ps/welcome.md)** - Management of Prepaid Services, one-off and periodic billing * **[DYCE Cockpit](/docs/cp/welcome.md)** - Configurable cues for tasks & priorities in the Role Center * **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** - Compilation of several products into a package; control which information appears on the customer side * **[DYCE Happy Texts](/docs/ht/welcome.md)** - Formattable long texts, greetings/after texts and images in documents; Defaults for professional documents * **[DYCE Record History & Favorites](/docs/rhf/welcome.md)** - Quick access to recently opened or favorite data records, directly in the Role Center * **[DYCE Essentials](/docs/general/essentials/welcome.md)** - Position numbers in sales documents, print preview of sales documents not yet posted, report configurations Further information and prices can be found on the related website. :::info Periodic Prepaid Services For periodic Prepaid Services, integration with Microsoft Subscription Billing is used. ::: ## Core benefits at a glance * **Project-oriented billing** Flexible invoicing based on time & material, budget or fixed price. * **Time recordings made easy** Modern web and mobile interface for quick entries. * **Prepaid Services** Management of quotas for services with one-off and periodic billing. * **Integration with Microsoft Subscription Billing** Automated processes for recurring services. * **Time saving and clean communication** **DYCE Happy Texts** for formatted long texts, pre/post texts and images; **DYCE Easy Bundle Seller** for a simplified external offer structure. * **Productivity at a glance** **DYCE Cockpit** for configurable cues; **DYCE Record History & Favorites** for quick access and tracking. ## Most important features of the Professional Services Suite * **Project billing** Billing according to project progress; support for fixed price, budget and Time & Material models; rule-based surcharges for work outside normal working hours. * **Time Recording** Recording of working times per project and task; mobile and web clients for flexible use. * **Prepaid Services** Management of quotas for services - one-off or recurring; Automatic invoicing in conjunction with Microsoft Subscription Billing. * **Productivity & communication** **DYCE Happy Texts**: formattable long texts, images, templates; **DYCE Cockpit**: configurable cues; **DYCE Record History & Favorites**: Quick access * **Integration with Subscription Billing** Automated billing of service quotas in conjunction with **DYCE Prepaid Services**. ### Overview of all features |Area|Feature|Description| |:--|:--|:--| |Time Recording|Web App for Time Recording|DYCE Connect as an intuitive web application for recording, correcting and approving times outside BC| |Time Recording|Bidirectional synchronization of the web application with Business Central|The synchronization between DYCE Connect and BC offers seamless integration. Data is automatically available in BC for further processing. Times are synchronized bidirectionally and in real time between BC & DYCE Connect| |Time Recording|Fast Time Recordings via Templates|Templates for recurring activities to record times as quickly and efficiently as possible| |Time Recording|Control the use of tasks|Centralized control option so that resources can only record times on tasks assigned to them in advance| |Time Recording|Task-based Time Recordings|Overview of the assigned tasks of the respective project employee and the possibility to record task-based times| |Time Recording|Light / Dark Mode|Individually switchable interface mode in light and dark mode as desired| |Time Recording|Outlook integration|Display of the Outlook calendar as the basis for time recording in DYCE Connect| |Time Recording|Dashboard for overview of Time Recordings|Display and control of recorded times in a visually appealing dashboard| |Time Recording|Integrations to Jira and Azure DevOps|Times can be recorded directly within the tasks in Jira and Azure DevOps and are immediately visible in DYCE Connect| |Time Recording|Mobile Version|Time Recordings also possible on smartphone or tablet| |Time Recording|Information on incomplete Time Recordings|Color highlighting and separate menu category for incomplete or missing times| |Time Recording|Multilingualism|Support for German and English| |Time Recording|Absences|Recording of absences as a list. Time Recordings are not expected for days with absences. Absences are displayed in the calendar as all-day appointments. |Time Recording|Attendances|Attendance times can be recorded regardless of Time Recordings. In many countries, the recording of daily working time is required by law. Recording the start and end of working time (duration of working time) and breaks. |Time Recording|Storage of different working time models & regional holiday calendars|With the help of working time models and resource calendars, any number of individual working time models can be realized| |Project billing|Linking sales orders and projects|By linking sales orders with projects, BC Sales and the project module grow together and enable control and billing of project-related services via the sales module| |Project billing|Creation of project tasks from the sales order|Generate project tasks directly from a sales order and plan the Budget for them| |Project billing|Different billing models|Time & Material, Budget (capping), Fixed Price| |Project billing|Project-related inclusion of external services/resources|Purchase and allocate external services or resources for projects| |Project billing|Automatic rounding of time recordings|Rounding of billable times to individually defined work units (e.g. quarter hours, half hours, etc.) for standardized and automated determination of the times to be billed| |Project billing|Possibility of pro-rata invoicing|Pro-rata billing of project employee times (e.g. 3h billable / 1h goodwill)| |Project billing|Central overview of open/released/to-be-booked times|Project billing includes a simple overview of open/released/to-be-booked times, which provides a central location for all open project times. |Project billing|Creation of invoices with service details|Billed times can be automatically shown in the invoice, providing the customer with a detailed overview of the services performed, including the times recorded as goodwill| |Project billing|Saveable views & filters for billing|Users (e.g. project managers) can create views & filters for the approval & booking of times and save them as templates| |Project billing|Quick filter / Quick filter in view|Ad-hoc filter in Project billing for exceptions / special cases| |Project billing|Proof of activity before invoicing|Create a proof of activity for the customer as proof before creating the invoice| |Project billing|Batch posting of checked times|Book any number of times easily and with just one click| |Project billing|Batch creation of invoices|Create any number of invoices with just one click| |Project billing|Review and release of time recordings|Review and release of time recordings by the project manager for forwarding to invoicing| |Project billing|Cancellation of Time Recordings|Cancellation of times in the event of an incorrect booking/complaint by the customer. This applies to both approved and booked times| |Project billing|Automatic creation of dimensions per project|Automatic creation of dimensions (so-called "tags") for evaluations for the respective project| |Project billing|Determination of invoiced shares|Determination of invoiced shares to allocate the revenue generated / billable times to the respective project employees based on the work performed. As the allocation is based on the Services provided, the allocation can vary (e.g. 50/50, 80/20 etc.). |Project billing|Profit and loss account (P&L) for individual projects|Profit and loss account (P&L) for individual projects with statistical accounts| |Project billing|Exact determination of the contribution margin by separating revenues & costs|The separation of revenues (sales) and costs (recorded times of the respective employee) shows exact profitability of the services sold in the project| |Project billing|Automatic determination of time-related surcharges|Surcharges for professional services fulfilled employees outside regular working hours are automatically determined and billed (e.g. for weekend work)| |Design sales documents|Create product bundles|Combine several products or services into one package| |Design sales documents|Predefined product bundles via item master data|Frequently used product bundles can be created as a separate item for easy and recurring use| |Design sales documents|Automatic price calculation and adjustment|Automatic calculation of the Bundle price from the individual prices as a proposal that can be adjusted| |Design sales documents|Distribute discounts|Distribute discounts to Bundle components as desired| |Design sales documents|Bundle prices|Definition of a Bundle price, which is distributed proportionally to the components| |Design sales documents|Format Bundles as desired|Control visibility/highlighting of Bundles and components| |Design sales documents|Subtotals|Freely definable subtotals in the sales documents| |Design sales documents|WORD and RDL layouts|Attractive Word and RDL layouts| |Design sales documents|Automatic Position Numbers|Automatic Position Numbers in Sales Documents| |Design sales documents|Configuring the footer|Setting up the footer depending on validity date and language| |Design sales documents|Configure logo position|Set up logo position left, center or right| |Design sales documents|Advanced description in sales documents|Unlimited and formattable texts in sales documents| |Design sales documents|Personal salutations & farewells|Individual greetings and closing texts in sales documents| |Design sales documents|Images in texts|Embedding images in texts| |Design sales documents|Editor add-in|Editor with paragraphs, lists, font formatting| |Design sales documents|Automatic integration in sales processes|Automatically insert texts in offers, orders, items| |Design sales documents|Text templates|Default templates can be defined and used automatically| |Design sales documents|CSS setup|Standard formatting customizable via CSS template| |Credit management|One-off Prepaid Services|Management of Prepaid Services that can be topped up as required| |Credit management|Prepaid Services with recurring top-up (e.g. monthly / quarterly / annually)| Prepaid Services in amounts that can be topped up as required| |Credit management|Prepaid Services in amounts or quantities|Prepaid Services can be displayed in amounts or quantities| |Credit management|Definition of the term|A start & end date can be defined for each Prepaid Service in which the Prepaid Services can be used| |Credit management|Definition of validity period (expiry date)|A validity period can be defined for each Prepaid Service. After the validity period has expired, the entitlement expires. |Credit management|Link with projects / Customers|Assign Prepaid Services to customers or projects| |Credit management|Integration with Microsoft Subscription Billing|Seamless integration into the BC Standard Sales & Subscription Billing module (e.g. for topping up periodically recurring Prepaid Services)| |Credit management|Automatic Offsetting|Automatic offsetting of invoice item and Prepaid Services| |Credit management|Remaining credit display|Display of remaining hours or amounts of Prepaid Services| |Credit management|Display whether a Prepaid Service is used in the project|Prepaid Services appear in the project billing| |Credit management|Topping up / extending existing quotas|Extending or extending Prepaid Services| |Credit management|Manual top-up|Prepaid Services can be topped up manually| |Credit management|Prepaid Services Statement|Status report on the status of the Prepaid Service(s) |Credit management|Automatic release of remaining amounts|(Partial) automatic release of remaining quantities or amounts| |Credit management|Automatic Dimension Value|Automatic Dimension Value per Prepaid Service for Evaluations| |Credit management|Automatic deferrals & revenue posting|With the initial invoicing, the amount is posted as deferrals and transferred to the revenue account upon consumption| --- ## API Connector for Dataverse # DYCE API Connector for Dataverse The **[DYCE API Connector for Dataverse](/docs/acd/welcome.md)** enables seamless integration between Microsoft Dynamics 365 Business Central and Dynamics 365 Sales (Dataverse). It ensures bi-directional synchronization of key data entities such as contacts, customers, opportunities, and related master data through automated jobs managed by wysa's [SalesCentral](/docs/acd/administration/setup-integration.md#SalesCentral) and [DataBridge](/docs/acd/administration/setup-integration.md#DataBridge) technology. :::info DYCE App Suites The app is not part of a bundle and can be purchased separately. However, we recommend contacting us for setup and use. Please follow the link for more information on **[DYCE API Connector for Dataverse](/docs/acd/welcome.md)**. ::: ## Key features at a glance * **Automated Synchronization** Scheduled jobs keep data consistent between Business Central and Dynamics 365 Sales. * **Mappings & Jobs** Predefined mappings and job configurations ensure accurate data flow and transformation. * **Integration** Standardized synchronization with custom API pages and mappings for additional entities. * **Enhanced User Experience** Business Central users benefit from Dataverse-linked fields and quick navigation to Sales records. --- ## Cockpit # DYCE Cockpit **[DYCE Cockpit](/docs/cp/welcome.md)** is an extension for Microsoft Dynamics 365 Business Central that enhances the standard role centers by providing customizable cues and filters for better visibility and control. **What is DYCE Cockpit?** * Adds a **My Cockpit** area to role centers. * Displays **cues** based on user-defined filters. * Each cue shows the **number of records matching** the filter criteria. * Up to **24 memory slots** for filters. :::info DYCE App Suites The app is part of several packages, but can also be downloaded separately. Please follow the link for more information on **[DYCE Cockpit](/docs/cp/welcome.md)**. ::: ## Key features at a glance * **User-Specific Filters** Create and manage filters manually or via templates. * **Dynamic Date Filters** Use date formulas for flexible filtering. * **Visual Indicators** Threshold-based color coding for cues. --- ## Connector for Jira Service Management # DYCE Connector for Jira Service Management The **[DYCE Connector for Jira Service Management](/docs/dcj/welcome.md)** seamlessly connects Business Central with Jira and enables an automated, fully controllable synchronization of customer and contact data between both systems. This efficiently bridges business and project management workflows. :::info DYCE App Suites The app is not part of a bundle and can be purchased separately. However, we recommend contacting us for setup and use. Please follow the link for more information on **[DYCE Connector for Jira Service Management](/docs/dcj/welcome.md)**. ::: ## Key features * Synchronization of customers and contacts, including Jira status and Jira ID displayed directly in Business Central * Synchronizing project and contract details as assets makes them available for selection on Jira work items for prefilling time recordings * Flexible entity and field mapping for full control over the data structure * Rule-based, automatic triggering of synchronization * Automatic assignment to Jira spaces based on defined criteria * Efficient delta synchronization and asynchronous processing with retry logic --- ## E-Document for Germany # DYCE E-Document for Germany The **[DYCE E‑Documents for Germany](/docs/edg/welcome.md)** app enhances the standard e‑document module in **Microsoft Dynamics 365 Business Central** with full support for **EN16931 compliant electronic invoices**, including **XRechnung (UBL Invoice)** and **ZUGFeRD (CII)**. It ensures seamless compatibility with all **DYCE‑specific features** and works **immediately without any configuration or additional permissions**. ## Why This App Exists Various DYCE apps extend or modify document creation - for example through bundles, extended descriptions, or fixed‑prices. These enhancements go beyond the Business Central standard and can cause incompatibilities in e‑invoice creation. Furthermore, service periods for professional services also need to be addressed. **DYCE E‑Document for Germany** ensures that all relevant DYCE functionalities are **correctly handled**, resulting in **consistency between PDF and e‑invoice**. ## Benefits - **Full EN16931 compliance** - **Zero configuration required** - Consistency between XML invoice and PDF layout - Fully future‑proof for German B2B e‑invoicing --- ## Project Billing # DYCE Project Billing **[DYCE Project Billing](/docs/pb/welcome.md)** is an extension for Microsoft Dynamics 365 Business Central designed to manage the entire lifecycle of professional services projects - from planning and budgeting to billing and controlling. **What is DYCE Project Billing?** It enables IT service providers and service-oriented companies to efficiently handle project-based services. It integrates seamlessly with other DYCE apps like **[DYCE Time Tracking](/docs/web/tt/welcome.md)** and **[DYCE Prepaid Services](/docs/ps/welcome.md)** (both part of **[DYCE Professional Services Suite](/docs/appsuites/pss.md)**) to provide a complete solution for service management. :::info DYCE App Suites Additionally, the app is included in the app bundles **[DYCE Professional Services Suite](/docs/appsuites/pss.md)** and **[DYCE Professional Services Suite Pro](/docs/appsuites/pss-pro.md)** but can be purchased separately. Please follow the link for more information on **[DYCE Project Billing](/docs/pb/welcome.md)**. ::: ## Key features at a glance * **Master Data Management** Define projects, resources, and configure service billing types (Time & Material, Budget, Fixed Price). * **Role Center for Project Billing** Access all project-related functions, including posted documents, time recordings, and purchase orders. * **Sales Integration** Link quotes and orders to projects, split budgets, manage bundles via **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)**, and configure document layouts. * **Billing & Invoicing** Generate project invoices individually or in batches, handle cancellations and credit memos, and preview unposted documents. * **Time Recording & Approval** Record time via **DYCE Connect**, approve time sheets, and manage billable vs. non-billable durations. * **Controlling & Evaluation** Automatic dimensions per customer/project, budget overviews, and resource evaluations using Business Central reports (Power BI coming soon). --- ## Record History & Favorites # DYCE Record History & Favorites **[DYCE Record History & Favorites](/docs/rhf/welcome.md)** is an extension for Microsoft Dynamics 365 Business Central that improves productivity by providing quick access to recently opened records and favorite entries directly in the role centers. **What is DYCE Record History & Favorites?** * Displays **Last Records** and **Favorites** lists in the role centers. * Allows users to **reopen records quickly** and mark important entries as favorites. * Supports up to **15 recent records** by default (configurable system-wide). :::info DYCE App Suites The app is part of several packages, but can also be downloaded separately. Please follow the link for more information on **[DYCE Record History & Favorites](/docs/rhf/welcome.md)**. ::: ## Key features at a glance * **Last Records** Automatically tracks recently opened records for easy navigation. * **Favorites** Add frequently used records to a favorites list for quick access. * **User-Friendly Actions** Functions like *Add to Favorites*, *Delete Entry*, and *Move Up/Down* for sorting. * **Shortcut Support** Use **CTRL+D** to add records to favorites instantly. --- ## Activation(Cp) The use of **DYCE Cockpit** is free of charge. Therefore, there is no billing. However, activation is required for use. A corresponding request is included in the standard Role Centers. For further information please refer to the DYCE Cockpit website. Activation is done using the app called **DYCE Monetization**. This application manages usage data for all DYCE subscriptions. Once activated, it continuously determines both activation status and usage data (e.g., number of users or transaction volume). ## Download, installation and activation **DYCE Cockpit** is provided via Microsoft AppSource for Microsoft Dynamics 365 Business Central. The DYCE Cockpit website also provides a corresponding link. In addition, Microsoft AppSource can also be accessed directly through Microsoft Dynamics 365 Business Central. To do so, search for *Extension Marketplace* (*Alt+Q*) and then for ***DYCE Cockpit***. Before downloading, Microsoft will request information for registration. If AppSource is opened directly through Business Central, this data is pre-filled based on the client's **Company Information**. In addition to registration in Microsoft AppSource, each app must be activated. This can be done for all DYCE apps in one step (collective activation). The full range of functions is only available once activation has been completed. In Role Centers and in selected pages, a corresponding notification appears as long as the activation has not yet taken place. To activate an app click on *Activate now* in the notification banner: 1. Start the activation wizard by clicking *Next*. 2. Enter your company information and register at **Singhammer IT Consulting AG**. 3. Select your Microsoft Dynamics 365 Business Central partner and payment method. 4. Accept end-user license agreement and finish activation. ### Activation status The activation status of all DYCE apps can be checked using the **DYCE Activation Status** page. The activation wizard can also be started from here. ## Allowing HTTP requests for DYCE Monetization After installation, a prompt appears asking if *HttpClient requests* are allowed. This immediately affects the *Allow HttpClient Requests* setting in **DYCE Monetization**. For the correct working of the app, make sure that *Allow HttpClient Requests* is set to *YES* (see below). We use HTTP requests to log your usage. We do not save any other data. Follow the steps to check or re-enable this option: 1. Go to the Extension Management page by typing *extension* in the search (*Alt+Q*). 2. Search for **DYCE Monetization** by **Singhammer IT Consulting AG** and click on *View* action (either via the three dots or via action group *Manage*). 3. Allow HttpClient requests :::danger Uninstalling DYCE Monetization If the ***DYCE Monetization*** app is uninstalled, **DYCE Cockpit** will also be uninstalled automatically. This can lead to unintentional data loss. ::: --- ## Cockpit(Cp) # DYCE Cockpit **DYCE Cockpit** is an extension of the standard Role Centers of Business Central. If the app is activated, user-specific filters can be created. These are displayed as cues in the **My Cockpit** area in the Role Center. ## Display of cues in the Role Center Each cue corresponds to a defined Cockpit filter. They always show the number of records that match the defined filter criteria. Via the page **My Cockpit Filters** the user can change the existing cues and add more. A total of 24 memory locations are available. :::warning Missing permissions When selecting a template or manually creating a filter, a check is made to see if the user has the required permissions to use the filter. If this is not the case, a corresponding error message appears. If the user does not have the required permissions to use the filter (which was assigned to him, for example, by an administrator), he receives a note in his Role Center (in the form of a *notification*), which permissions he lacks for the execution of a Cockpit filter. The tile then shows *No read permission* as description and a counter of *0*. ::: :::note Note After creating or deleting a Cockpit filter, the client or Business Central app must be closed and restarted after closing the **My Cockpit Filters** page. A notification alerts the user to this and enables the restart directly. ::: --- ## Setup(Cp) # Setup of DYCE Cockpit This page describes how to create your own filters, how to handle filter templates and how to manage them centrally. ## Filters To manage your own filters, click on the heading **My Cockpit**. A dropdown menu opens, in which the view can be updated ad hoc or the filters can be managed (*Manage list*). In the opening page **My Cockpit filters** all filters of the current user are displayed. Alternatively, the page can also be accessed via the search (*Alt+Q*). The page is structured as follows: 1. **Fields** - Via **Filter Preset** an existing template can be selected. A template can contain all characteristics of a filter. This includes the table containing the records and the page used to display the records, as well as predefined filters (e.g. on a specific Document Type or a date filter) and thresholds with indication colors. The use of templates is optional. Thus, a Cockpit filter can also be defined manually, without using a template. - The **Description** will later be used as a heading for the cue in the Role Center. - **Table** and **Page** specify the location of the filtering records and the page that displays the records. - Clicking on the **Filter** flowfield opens the page where the filter criteria can be determined. Here all fields of the specified table are available. - If a date filter is set via **Date Filter Field** and **Date Filter** (see info box *Dynamic Date Filters*), this will also be displayed in the filter page. Via **Date Filter Field** a date field can be selected from the defined table. The value in **Date Filter** determines which filter value is applied to the date field. Here, both a concrete date and, above all, date formulas in connection with operators can be stored. The dateformula depends on the language set in the client and is interpreted by the filter page and by the cues in the Role Center based on the workdate. - The remaining fields can be used to set threshold values for the color display of the cues. - **Low Range Style** specifies the color of the cue if the value of the data in the stack is less than the value specified in the *Threshold 1** field. - **Threshold 1** specifies the value for the stack above which the cue color changes to the color specified in the *Middle Range Style* field for lower values. - **Middle Range Style** specifies the color of the cue when the value of the data in the stack is greater than or equal to the value in the *Threshold 1* field, but less than or equal to the value in the *Threshold 2* field. - **Threshold 2** specifies the value for the stack above which the cue color changes to the color specified in the *High Range Style* field for higher values. - **High Range Style** specifies the color of the cue when the value in the stack is greater than the value in the *Threshold 2* field. 2. **Actions** - A preview of the result or filtered records of the current Cockpit filter is given by **Show Records**. The corresponding page with the specified filters is called up. - Analogous to clicking on the **Filter** flowfield, the filter page can also be called up via **Edit Filter**. - With **Copy Filter** a copy of the current Cockpit filter is created. This is always useful if a filter similar to the one already created is required. The deviating filter criteria can then be set. - Via **Move Up** and **Move Down** the order of the filters can be changed. :::info Page Filter If the specified page contains a fixed filter, e.g. for the Document Type, this must be explicitly specified as **Filter**. **Example** Sales Header and Document Type The *Sales Header* table and the *Sales Orders* page are used to display Sales Orders. The *Sales Orders* page has a fixed filter for the **Document Type**=*Order*. If a filter on Sales Orders is created manually (without a preset) and the *Sales Orders* page is used for this, the **Document Type**=*Order* must be explicitly specified as a filter. Predefined **Filter Presets** already take the necessary filters into account. ::: ### Dynamic Date Filters A dynamic date filter is always useful if the filter date is not to be specified absolutely, e.g. if the period between today and in a week is to be considered. For such cases, a dateformula can be specified, which references the workdate in the calculation. Furthermore, a dateformula can also be combined with other operators. * **Example for a dynamic date filter** Workdate (see page **My settings**): 26.07.2024 Dateformula with operator: w..w+8D (meaning: the interval between the workdate and the workdate + 8 days) Result: 26.07.2024..02.08.2024 For more information about date filters and operators, see the Microsoft documentation at Using Date Formulas and Filter Criteria and Operators. ## Presets Cockpit filter templates can be accessed via the **Filter Preset** field (in the **My Cockpit Filters** page) or via search (*Alt+Q*, **Cockpit Filter Presets** page). Besides the **Description** of the template, the other fields are identical to those in the **My Cockpit filters** page. Analogous to the Cockpit filters, the presets can also be copied (**Copy Preset**) if required (assuming appropriate [permissions](#permissions)). Further individual filter criteria can be added via the **Edit Filter** action. In addition, experienced users or administrators (given they have the required [permissions](#permissions)) can create new Cockpit filter templates and thus add to the list of available templates as desired. In principle, all tables of the application for which a list page exists can be used for the creation of templates. This requires appropriate knowledge of the table and page structure. The *Page Inspection* (see Help & Support, Inspect pages and data) can be helpful here. To exchange filter templates with other environments (e.g. after successful testing in a sandbox), the templates can be exported or imported using the actions **Export Presets** and **Import Presets**. When exporting, an XML file is created. It always contains all existing templates. ## Administration The **Cockpit Filters Administration** page, which can be accessed via the search (*Alt+Q*), shows the Cockpit filters of all users. The page is primarily used for central administration. In addition to the actions **Show records**, **Edit Filter**, **Copy Filter** and **Move Up**/**Move Down** described above, it is also possible here via **Copy Filters to Users** to copy one or more filters from one user to another. :::warning Missing permissions When the action **Copy Filters to Users** is executed, it is checked whether the assigned user has the required permissions to use the filter. If this is not the case, a notification is issued, but the assignment of the filter is carried out. This can be useful if the user is subsequently granted the required permissions. Otherwise the user gets a hint (in form of a *notification*) in his Role Center, which permissions he is missing for the execution of a Cockpit filter. The tile then shows *No read permission* as description and a counter of *0*. ::: ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCECOCKPITALL (DYCE Cockpit Read)** This permission set can be assigned to all users. It contains read-only permissions to use predefined Cockpit filters assigned to users. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCECOCKPITUSER (DYCE Cockpit Edit)** This permission set is for all users who should be able to create their own filters. The creation of templates is not permitted with these permissions. However, filters can be copied for yourself and for other users (via the **Cockpit Filter Management** page). The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCECOCKPITADMIN (DYCE Cockpit Admin)** This permission set is designed for administrators and power users who should additionally be able to create templates and areas. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information about permission sets, see this part of the Microsoft documentation. ### Supported Role Centers **DYCE Cockpit** extends the Role Centers of the following standard profiles of Business Central: |Profile|Display Name|Role Center ID |:--|:--|:--| ACCOUNTANT|Accountant|9027 BUSINESS MANAGER|Business Manager|9022 DISPATCHER|Service Manager|9016 ORDER PROCESSOR|Sales Order Processor|9006 PRODUCTION PLANNER|Manufacturing Manager|9010 PROJECT MANAGER|Project Manager|9015 SALES AND RELATIONSHIP MANAGER|Sales and Relationship Manager|9026 SECURITY ADMINISTRATOR|Administration of users, user groups and permissions|9024 SHIPPING AND RECEIVING|Inventory Manager|9008 SHIPPING AND RECEIVING - WMS|Shipping and Receiving - Warehouse Management System|9000 TEAM MEMBER|Team Member|9028 WAREHOUSE WORKER - WMS|Warehouse Worker - Warehouse Management System|9009 --- ## Document Tracker # Document tracking **DYCE Document Tracker** finds all transactions belonging to a document. In addition, it can also be used separately to search for a specific document - without the user having to know which document type (Invoice, Purchase Order, Sales Order, etc.) is involved. ## Supported document types The following document types are found by **DYCE Document Tracker**: * Opportunities * Sales Quotes * Archived Sales Quotes * Sales Orders * Archived Sales Orders * Posted Sales Shipments * Sales Invoices * Posted Sales Invoices * Sales Credit Memos * Posted Sales Credit Memos * Purchase Orders * Archived Purchase Orders * Posted Purchase Shipments * Posted Purchase Invoices * Projects * Project Tasks * Production Orders (simulated, planned, firmly planned, released, finished) Document tracking can be called using the search (Alt+Q) and in document headers. In the document header the action can be found in the menu with the same name as the document type (e.g. menü Order in the Sales Order). :::info When using the document tracking, only those records are displayed that the user is allowed to open based on his access permissions. Therefore, it is possible that different results are displayed to different users with different permissions. ::: --- ## Setup(Dt) # Setup of DYCE Document Tracker **DYCE Document Tracker** does not require any setup. ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCEDTALL (DYCE Document Tracker Read)** This permission set can be assigned to all users. It only includes the necessary read permissions to use document tracking. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCEDTEDIT (DYCE Document Tracker Edit)** This permission set is for all users who should be able to work with **DYCE Document Tracker**. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCEDTADMIN (DYCE Document Tracker Admin)** This permission set just includes DYCEDTEDIT permission set. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information on permission sets, see this part of the Microsoft documentation. --- ## Activation(Rhf) The use of **DYCE Record History & Favorites** is free of charge. Therefore, there is no billing. However, activation is required for use. A corresponding request is included in the Role Centers. For more information, please refer to the DYCE Record History & Favorites website. Activation is done using the app called **DYCE Monetization**. This application manages usage data for all app subscriptions. Once activated, it continuously determines both activation status and usage data (e.g., number of users or transaction volume). ## Download, installation and activation **DYCE Record History & Favorites** is provided via Microsoft AppSource for Microsoft Dynamics 365 Business Central. The DYCE Record History & Favorites website also provides a corresponding link. In addition, Microsoft AppSource can also be accessed directly through Microsoft Dynamics 365 Business Central. To do so, search for *Extension Marketplace* (*Alt+Q*) and then for ***DYCE Record History & Favorites***. Before downloading, Microsoft will request information for registration. If AppSource is opened directly through Business Central, this data is pre-filled based on the client's **Company Information**. In addition to registration in Microsoft AppSource, each app must be activated. This can be done for all DYCE apps in one step (collective activation). The full range of functions is only available once activation has been completed. In Role Centers and in selected pages, a corresponding notification appears as long as the activation has not yet taken place. To activate an app click on *Activate now* in the notification banner: 1. Start the activation wizard by clicking *Next*. 2. Enter your company information and register at **Singhammer IT Consulting AG**. 3. Select your Microsoft Dynamics 365 Business Central partner and payment method. 4. Accept end-user license agreement and finish activation. ### Activation status The activation status of all DYCE apps can be checked using the **DYCE Activation Status** page. The activation wizard can also be started from here. ## Allowing HTTP requests for DYCE Monetization After installation, a prompt appears asking if *HttpClient requests* are allowed. This immediately affects the *Allow HttpClient Requests* setting in **DYCE Monetization**. For the correct working of the app, make sure that *Allow HttpClient Requests* is set to *YES* (see below). We use HTTP requests to log your usage. We do not save any other data. Follow the steps to check or re-enable this option: 1. Go to the Extension Management page by typing *extension* in the search (*Alt+Q*). 2. Search for **DYCE Monetization** by **Singhammer IT Consulting AG** and click on *View* action (either via the three dots or via action group *Manage*). 3. Allow HttpClient requests :::danger Uninstalling DYCE Monetization If the ***DYCE Monetization*** app is uninstalled, **DYCE Record History & Favorites** will also be uninstalled automatically. This can lead to unintentional data loss. ::: --- ## Favorites Each record in the list **Favorites** can be opened by clicking the number (**No.**) in the 1st column. Alternatively, a record can be opened by marking the entry and using **Show record** in the assist edit or drop-down menu in the header. ## Refreshing Favorites The list is refreshed automatically on adding or deleting an entry. The list of record entries is refreshed once the Role Center is refreshed / loaded. The list can be refreshed manually by using **Refresh** in the header drop-down menu. ## Automatic deletion of records If a record is deleted the entry will be deleted automatically. ## Deleting record entries Records can be deleted using **Delete entry** in the drop-down menu or the line assist edit. All records can be deleted using **Delete all** in the header drop-down menu. :::info Deleting a record entry in the list **Favorites** will not delete the actual record. ::: ## Adding to favorite The function **Add to favorites** in **Last Records** in the header drop-down and line assist edit is the only way to add a record to the list of favorites. ## Sorting favorite entries The functions **Move up** and **Move down** in the header drop-down menu can be used to move entries up and down. --- ## Last Records Each record in the list **Last Records** can be opened by clicking the number (**No.**) in the first column. Alternatively, a record can be opened by marking the entry and using **Show record** in the assist edit or drop-down menu in the header. ## Refreshing records The list of record entries is refreshed once the Role Center is refreshed / loaded. The list can be refreshed manually by using **Refresh** in the header drop-down menu. ## Automatic deletion of records In the default setting 15 record entries are saved. If the user opens the 16th record the oldest record entry will be deleted. If a record is deleted the entry will be deleted automatically. ## Deleting record entries Record entries can be deleted using **Delete entry** in the drop-down menu or the line assist edit. All records can be deleted using **Delete all** in the header drop-down menu. :::info Deleting a record entry in the list **Last Records** will not delete the actual record. ::: ## Adding to favorite The Last Records entries can be used to mark a record as a favorite. For this purpose, the function **Add to favorites** is available in the header drop-down and line assist. :::tip The **Add to Favorites** function can also be performed by using the shortcut *CTRL+D*. ::: --- ## Setup(Rhf) # Setup of DYCE Record History & Favorites There is no setup required after installing **DYCE Record History & Favorites**. Make sure to add at least the permission set **DYCERHFREAD (DYCE Record Hist. & Fav. Read)** to all users, which are suppose to use **DYCE Record History & Favorites**. If the parts do not show up in the Role Center insert them using the personalization. ## Maximum number of Last Records If an administrator wants to set the number of entries in the Role Center part **Last Records** system-wide, the **Last Records Setup** page is available for this purpose. The default setting is 15 entries. If you set the number to 20, the last 20 records opened will be saved. ## Permissions {#permissions} This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCERHFREAD (DYCE Record Hist. & Fav. Read)** This permission set can be assigned to all users. It contains all the permissions needed to use **DYCE Record History & Favorites**. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCERECORDHISTORY (DYCE Record Hist. & Fav. Edit)** This permission set is for all users who actually work with **DYCE Record History & Favorites** and who should be able to save favorites. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCERHFADMIN (DYCE Record Hist. & Fav. Admin)** This permission set is designed for administrators and power users who should additionally be able to change the maximum number of entries in the Role Center part **Last Records** system-wide. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information about permission sets, see this part of the Microsoft documentation. ## Included in Role Center The parts are available in the following Role Centers. These are the Role Centers that are activated by default. |Profile|Display Name|Role Center ID |:--|:--|:--| ACCOUNTANT|Accountant|9027 AR ADMINISTRATOR|Accounts Receivable Administrator|9077 BUSINESS MANAGER|Business Manager|9022 DISPATCHER|Service Manager|9016 ORDER PROCESSOR|Sales Order Processor|9006 PRODUCTION PLANNER|Manufacturing Manager|9010 PROJECT MANAGER|Project Manager|9015 SALES AND RELATIONSHIP MANAGER|Sales and Relationship Manager|9026 SECURITY ADMINISTRATOR|Administration of users, user groups and permissions|9024 SHIPPING AND RECEIVING|Inventory Manager|9008 SHIPPING AND RECEIVING - WMS|Shipping and Receiving - Warehouse Management System|9000 TEAM MEMBER|Team Member|9028 WAREHOUSE WORKER - WMS|Warehouse Worker - Warehouse Management System|9009 ## Pages guaranteed to be included in DYCE Record History & Favorites All Business Central and DYCE card pages will be recorded and saved. --- ## Bundles Bundles allow you to combine multiple items into one *sales package*. They can be defined in the item master data as well as created on-the-fly in most sales documents. A Bundle behaves like a product/item that consists of different components. Bundles unfold their full potential for a clear structuring of sales documents in combination with [Formatting](/docs/ebs/formatting.md) which is also part of **DYCE Easy Bundle Seller**. On Sales Quotes, a whole bundle can also be marked as an alternative choice or an optional add-on using the [Alternative and Optional Positions](/docs/ibt/alternative-optional-positions.md) feature from **DYCE IT-Business Toolkit**. :::warning Restrictions Bundles cannot be used if items from other software are added to the sales line. This includes Dynamics 365 Sales and the Shopify Connector. The ability to transfer a bundle from another software is currently under review. Furthermore, nested bundles are not possible. ::: ## Product bundle A bundle is a combination of individual components into a standalone product. It can be used in **Sales Quotes** and **Sales Orders** (from here on called *sales documents*). The price of the bundle is based on the prices of the components. Bundles can be used based on [master data](#master-data-for-bundles) or created [individually (on-the-fly)](#creating-a-custom-bundle). ### Master data for bundles To use fixed bundles, they can be created in the master data of the items. This allows easy use e.g. in a sales offer. For this purpose, a new item is created to be used for a product bundle. The description of the bundle is entered in the item's description. The **Bundle** field (on the Item card in the *General* fast tab) is set to *YES*. :::info The item representing the bundle must be set as *inventory managed* (**Type**=*Inventory*). This is Business Central's requirement for an assembly bill of materials to be created. However, this is not further relevant to the use of the item, as the item will be converted to a text line when used in a sales document. ::: Subsequently, the components for the bundle are stored via the **Assembly BOM** (call via *Related / Bill of Materials / Assembly*). The moment a Bundle item is used in a sales line and a quantity is entered, the related BOM is automatically unfolded. In this process, the line with the Bundle item is converted to a text line (field **Grouping**=*Bundle*), and the entries in the BOM become components. The system also takes into account settings from **[Sales & Receivables Setup](/docs/ebs/setup.md#sales--receivables-setup)**. :::warning Important If the rollout of a Bundle is interrupted by a dialog, request page or other popups, it is possible that the Bundle will not be rolled out completely. The Bundle is then potentially only rolled out up to the point of interruption. During the interruption, some information must be saved in the database (commit). When saving, however, the instruction to create further Sales lines and mark them as components gets lost. ::: For more details on how assembly BOMs work, please see this part of the Microsoft documentation. Only items for professional service whose **Service Billing Type** is *Budget* can be used as components of a Bundle. The background to this is that Bundles can only be shipped and invoiced *as a whole*. Neither is possible with the Service Billing Types *Time & Material* and *Fixed Price*. ### Create Bundles via other Apps or Api Bundle items that are entered in Sales lines via other apps or an API are not automatically exploded, if setHideValidateDialog(true) or GUIALLOWED(false) applies. This prevents the Sales line from being changed by **DYCE Easy Bundle Seller** before the other app has finished creating it. For example, if the Shopify Connector were to enter a Bundle item in a Sales line and set the quantity, the Bundle would be immediately explode. The Sales line with the Bundle is now a comment/text line. The Shopify Connector can no longer enter the price and runs into an error. If the quantity is entered in a Bundle when neither setHideValidateDialog(true) nor GUIALLOWED(false) does apply, the Bundle is exploded immediately. For the user, the Bundle is always going to exploded automatically, while for other apps or an API it will not. Bundle items are prevented from being posted in order to prevent incorrect data. The user can explode the Bundle via the line action **Explode Bundle**. The action is available in Sales Quotes, Sales Orders, Blanket Sales Orders, Sales Invoices and Sales Credit Memos. Additionally, an action has been made public in **DYCE Easy Bundle Seller** to explode Bundles automatically again. This can be used to create a connector app. In the *Codeunit 70921400 DYCEEBSBundleManagement* the procedure *"ExplodeBundleLinesInSalesDocument(SalesHeader: Record "Sales Header") "* can be called by a connector app. The action explodes all Bundles in the selected document. For example, to connect the Shopify Connector, the event *"Order.Events.OnAfterProcessSalesDocuments(SalesHeader,OrderHeader) "* in *Codeunit 30166 "Shpfy Process Order" (ShpfyPreocessOrder.Codeunit.al)* could be utilized to explode all Bundles in the document. ### Creating a custom bundle In addition to using a *predefined* bundle (see above), an individual or one-time bundle can also be created manually within a sales process. For this, a line of the type *Comment* (text line) must be created in the first step. In the text line, the description is entered and the indicator in the **Grouping** field is changed to *Bundle*. The Bundle is initially created with quantity 1. In the following lines the components (*items*) are entered. These lines are marked as *Components* in the **Grouping** field. In the component lines, the quantities are entered that result in exactly one Bundle. Afterwards, the bundle can be edited in the **Bundle** page. The page is called up via the function **Edit Bundle** in the line menu (*Manage* in the sales document). Here, Unit of Measure as well as Quantity, Discount and the Unit Price of the bundle can be edited. In the sales documents, increasing the quantity in the bundle will correspondingly increase all quantities in the components. ### Defaults for custom bundles To facilitate the creation of a bundle on-the-fly, defaults can be stored via the **Bundle Unit of Measure**, **Bundle Line Format Style** and **Bundle Print Components** fields in the **[Sales & Receivables Setup](/docs/ebs/setup.md#sales--receivables-setup)** page in the **Bundle** fast tab. These entries are optional. If these fields are not filled, they must be assigned when [creating an individual Bundle](#creating-a-custom-bundle). :::tip If you want to quickly go to the page for **Bundle**, you can get the **Bundle Description** field via personalization. Clicking on the field will open the **Bundle** page. ::: If a sales document contains multiple bundles, a selection window for assigning the component to the desired bundle is displayed when components are entered. The bundle that is next above the component is always suggested (highlighted). By confirming the selection, the component is assigned to the bundle. ## Prices and discounts in the Bundle {#prices-and-discounts-in-the-bundle} Unit price, amount and discount amount of a bundle are calculated based on the components. The unit price of a bundle (**Unit Price Excl. VAT** or *bundle price*) is calculated by dividing the sum of the amounts and discount amounts of the components by the bundle quantity: ```math Bundle \ price = \frac{1}{Bundle \ quantity} \sum\limits_1^n quantity \ component_i*price \ component_i ``` The line amount of a bundle (**Line Amount Excl. VAT** or *bundle amount*) is equal to the sum of the component amounts: ```math Bundle \ amount = \sum\limits_1^n amount \ Component_i ``` The discount of a bundle (**Line Discount Amount** or *bundle discount*) is equal to the sum of the discount amounts of the components: ```math Bundle \ discount \ amount = \sum\limits_1^n (discount \ amount \ component_i) ``` If a component is added or removed from a bundle or the price of the component is changed, the bundle's price, amount, and discount are recalculated. If the quantity of a component is changed, the bundle's amount and discount will be recalculated. If a discount is entered, changed or deleted in a component, the amount and discount in the bundle will be recalculated. Subscription Items are not included in the bundle price, amount and discount calculation. Changes in components will immediately result in a change in the bundle. This includes quantity-based component price changes caused by quantity changes in the bundle. The quantity, price, discount and amount of the bundle can be changed using the **Edit Bundle** line action. A quantity change in the bundle will change the quantities of the components. Bundle amount and discount will be recalculated. If the quantity of a component is changed, the price is also recalculated, provided that there are entries in a Sales Price list. In case of a price change in a bundle, the prices of all components are recalculated. In this case, the prices of the components are changed by the same proportion as the bundle price was changed. If after the price change of the components the newly calculated bundle price does not match the manually entered bundle price, the difference is calculated down to *one* bundle (quantity = 1) and added to the price of one component. For this second step, the optimal component is determined. If a component and the bundle have the same quantity, the component is optimal and used to make up the difference. If there is more than one component with the same quantity, the last one is used. If there is no component with the same quantity, the last component is used. ```math Price \ component_i = Old \ price \ component_i* \frac{New \ Bundle \ price}{Old \ Bundle \ Price} ``` ```math Price \ Component_i = Calculated \ Price \ Component_i* \frac{New \ Bundle \ price \ - \ Calculated \ Bundle \ Price}{Bundle \ quantity} ``` :::warning Rounding precision When calculating the bundle price, **Unit-Amount Rounding Precision (LCY)** from General Ledger Setup is used. Since the number of decimal places, that can be used in Business Central is limited, it is possible, that due to the rounding of the component prices, the manually entered bundle price (and the amount calculated from it) no longer match the totals of the components. In this case, the bundle price is recalculated from the components and applied. **Example** (rounded to 5 decimal places) |Grouping|Quantity|Price|Amount| |:--|:--|:--|:--| |**Bundle**|**2**|**10.078,-**|**20.156,-**| |Component 1|10|125,-|1.250,-| |Component 2|12|123,-|1.476,-| |Component 3|42|415,-|17.430,-| New bundle price: 10.000,- |Grouping|Quantity|Price|Amount| |:--|:--|:--|:--| |**Bundle**|**2**|**10.000,0088**|**20.000,0176**| |Component 1|10|124,03255|15504,06875| |Component 2|12|122,04803|15011,90769| |Component 3|42|411,78847|170892,21505| Using a proportional price change of the components, it is not possible to solve problems of this type. It is possible to calculate matching prices, but the price changes would appear random, which is why we refrain from doing so. Example for clarification: |Grouping|Quantity|Price|Amount| |:--|:--|:--|:--| |**Bundle**|**2**|**10.000,-**|**20.000,-**| |Component 1|10|125,-|1.250,-| |Component 2|12|124,-|1.488,-| |Component 3|42|411,-|17.262,-| The prices solve the problem mathematically, but the price changes of the components do not follow a clear logic. ::: If a **Line Discount %** or **Line Discount Amount** is entered in the bundle, the percentage discount of the bundle is calculated and applied to all components. A discount can be entered among other things by changing the bundle amount. If the discount in the bundle is deleted, all discounts of the components are deleted. Subscription Items are taken into account when setting discounts in the bundle. If a discount is entered in a Subscription Item, it will *not* be included in the calculation of the discount of the bundle. ## Rounding of price and amount The number of decimal places to be used can be set up in Business Central (s. rounding precision in **General Ledger Setup**). If the rounding precision for Unit Price and Amount differ, it is possible to create Bundles in which Unit Price and Amount cannot be calculated in the conventional way. Normally, the Unit Price of a Bundle is calculated as the sum of the Unit Prices of the components and the Amount of a Bundle is calculated as the sum of the Amounts of the components. For example, if Unit Prices use a rounding precision of 5 decimal places and Amounts use a rounding precision of 2 decimal places, *Quantity x Unit Price* and *Amount* in the Bundle could differ due to rounding. To prevent *Bundle Unit Price x Bundle Quantity* from differing from the *Bundle Amount*, the Bundle Unit Price is calculated from the Bundle Amount and the Bundle Quantity in the event of differences. ```math Bundle \ price = \frac{bundle \ amount}{bundle \ quantity} ``` :::info Example |Grouping|Quantity|Unit Price|Amount| |:--|:--|:--|:--| |**Bundle**|**1**|**2.00**|**2.00**| |Component 1|1|1.11111|1.11| |Component 2|1|0.88888|0.89| The sum of the Unit Prices of the components equals 1.99999. The sum of the Amounts of the components equals 2.00. The Bundle line would therefore be printed with Quantity 1, Unit Price 1.99999 and Amount 2.00. To counteract the inaccuracy caused by rounding, the Bundle Unit Price is calculated from the Bundle Amount. This ensures that Unit Price and Amount of the Bundle match when printed. This procedure could potentially cause inaccuracies when manually changing Bundle Unit Prices and recalculating component prices. However, no such case is currently known. ::: ## Dimensions for bundles In sales documents, dimensions can be entered directly on the bundle. The behavior of dimensions for bundles in sales documents is controlled in the **[Sales & Receivables Setup](/docs/ebs/setup.md#sales--receivables-setup)** page in the **Dimensions** fast tab via the **Bundle Dimension Priority** field. ## Shipment of a bundle Item shipment behaves identically with and without a bundle. :::info The quantities of the components cannot be adjusted after the initial shipment. The bundles quantity, on the other hand, can still be adjusted after delivery. The **Bundle Qty. Shipped** and **Bundle Qty. Invoiced** fields can be viewed directly in the bundle. ::: ## Invoice bundle in sales document In the Sales Order, the bundle is treated as a standalone product during billing. It can only be billed if it is shipped as a *whole*. Components in a bundle cannot be billed independently. I.e. only as many bundles can be invoiced as whole bundles were shipped. If a bundle consists of two components and only one is shipped, it is not a complete bundle and therefore cannot be invoiced. If both components are shipped, the bundle can be invoiced. Accordingly, **Qty. to Invoice** is set in the components so that bundles are always invoiced as a whole. :::info If a component is to be explicitly invoiced individually, the bundle can be dissolved at any time. To dissolve the bundle, either the bundle line must be deleted or the *Bundle* flag must be removed. The bundle cannot be reassembled after dissolution. New sales lines must be created for the quantities not yet shipped and a new bundle created if necessary. ::: ## Bundles in Prepayment Invoices In Sales Orders, Bundles are treated as standalone products. The same applies to Prepayment Invoices. If one component is assigned to a Payment Plan Step, the whole Bundle with all components is automatically assigned. The bundle line is created with quantity 1 in the Prepayment Invoice. The formatting of the Sales lines, Components and Bundle line are transferred to the Prepayment Invoices. --- ## Formatting Formatting is used to control what content and how that content is printed on print documents. This control allows, among other things, the printing of headings and the hiding of components. Formatting can be used in the following sales documents: * Sales quotes * Sales orders * Blanket orders * Sales invoices * Sales credit memos * Customer Subscription Contracts (if **[Microsoft Subscription Billing](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/welcome)** is used) Formatting can no longer be changed in posted documents. It will be applied when posting and when creating the subsequent document. Thus the formatting is copied from the sales quote to the sales order. The formatting can again be adjusted in the sales order. ## Changing the formatting The formatting can be customized in the lines of the documents as follows: * The **Print Line** field controls whether a line should be printed. The line amount goes into the document amount regardless of whether a line is printed. * **Formatting** field specifies the output of the line or whether it should be printed *bold*, *italic* or *normal*. On Sales Quotes, this field is also set automatically to *Italic* by the [Alternative and Optional Positions](/docs/ibt/alternative-optional-positions.md) feature from **DYCE IT-Business Toolkit** when a line is marked as an alternative or optional position. * **Print Discount %** controls whether the discount % from the line is printed on the receipt. * **Print Quantity Only** option prints the line with the quantity only. **Unit price**, **Discount %** and line amount will not be printed or will be printed with the value 0. * A page break can be inserted via **New page**. The line with the indicator is always printed on a new page. :::warning Page breaks The page break that can be triggered via the **New page** field only affects RDL layouts for technical reasons. Page breaks cannot be realized with WORD layouts using this method. ::: :::tip Headings Headings can be used to easily structure sales quotes, order confirmations and invoices to increase readability. A heading can be easily created using the **Formatting** and **New Page** fields. Enter a line of text and select the *Bold* option in the **Formatting** field. If you want the heading to start on a new page, set the indicator accordingly. ::: ## Formatting for bundles [Bundles](/docs/ebs/bundles.md) are, from a system point of view, independent products consisting of different components. In most cases the components should be printed without price, *italic* or not at all. In these cases, formatting quickly creates an easy-to-read print document. If you want to print the bundle without the components, simply uncheck **Print Line** in the component lines. This will print only the bundle, while you have created all the necessary components in the lines and can work with them. If you want the components to be printed without prices, this can be controlled by the **Print Quantity Only** field. If you want to highlight the bundle, change the **Formatting** in the bundle line to *Bold*. Readability and clarity of the print document will be increased. ### Default for bundles via Assembly BOMs Since bundles can also be stored as [master data](/docs/ebs/bundles.md#master-data-for-bundles), the fields **Print Line**, **Formatting**, **Print Discount %** and **Print Quantity Only** are also available in the bill of materials list (assembly parts). This allows you to define specifications for the formatting of the sales lines to be created in advance. When the components list is rolled out, the specifications are transferred to the sales lines, but can be changed here afterwards. --- ## Setup(Ebs) # Setup of DYCE Easy Bundle Seller **DYCE Easy Bundle Seller** does not necessarily require any special setup. However, additional report layouts (WORD and RDL) are included with the app. For more information, please refer to [this](#handling-layouts-and-hints-to-developers) part and the following sections of the DYCE documentation. ## Sales & Receivables Setup The **Bundle Dimension Priority** field controls which dimensions are stored on the components of the bundle. Dimensions can be automatically transferred from the bundle line to components, component dimensions can be automatically retained, or a selection can be shown for each bundle to manually specify. * The *Dimensions from BOM* option will transfer all dimensions from the bundle to the components. If there are conflicts between the Dimension Values of the bundle and the component, the Dimension Values of the component will be overwritten. Additional dimensions stored on the component will not be changed. * With the option *Dimensions of components* the dimensions from the bundle have no influence on the components. * With the option *Show selection* a selection window with the above two options is shown. To facilitate the creation of a bundle on-the-fly, default values can also be stored via the fields **Bundle Unit of Measure**, **Bundle Line Format Style** and **Bundle Print Components** (in the **Bundle** fast tab). These entries are optional. If these fields are not filled, they must be assigned during the [creation of a custom bundle](/docs/ebs/bundles.md#creating-a-custom-bundle). The use of the **Print Sub-Total** and **Subscription Item in Bundle** fields is described in the section **[Subtotals](/docs/ebs/subtotals.md#key-rules-and-system-behavior)**. ## Handling layouts and hints to developers **DYCE Easy Bundle Seller** contains additional layouts (WORD and RDL) for the relevant standard reports from Business Central. These layouts are based on the standard layouts for the relevant reports. They can either be used out-of-the-box or are used to apply the relevant changes to the deployed (custom) layouts. For more information on layouts and notes for developers, please refer to [this](/docs/ebs/supported-layouts.md) part of the DYCE documentation. ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following permission set is included with the app: * **DYCEEBSALL (DYCE Easy Bundle Seller All)** This permission set is for all users who should be able to create and work with bundles. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). For more information about permission sets, see this part of the Microsoft documentation. --- ## Subtotals This feature is designed to make your sales documents clearer and more readable for customers, especially for quotes with multiple sections like software licenses, professional services, or hardware. ## Key user benefits * Improved readability: Break down extensive sales documents into logical blocks (e.g., *Software modules* or *Implementation*). * Clearer pricing: Each block can have a visible subtotal, making it easy for the customer to see the cost of each group of items. * Automated calculations: The subtotal is automatically calculated and maintained as you edit the items within the block. ## How to create a subtotal block You can set up subtotals on sales quotes, sales orders, sales invoices, and sales credit memos. **Step 1: Add comment lines** 1. Create a comment line right above the first line of the block you want to total. This will be your header line. 2. Create a second comment line right below the last line of the block. This will be your footer line. **Step 2: Define the block boundaries** The core of this feature is a new option in the **Grouping** field on the sales line. 1. On the header comment line (the top line of your block), select the new option *Begin-Total*. 2. On the footer comment line (the bottom line of your block), select the new option *End-Total*. :::info What happens next? As soon as you set the *End-Total*, the system recognizes the start and end of the block. It instantly calculates the sum of the **Line Amount** and the total **Discount Amount** for all item lines between the two comments. ::: **Step 3: View the resulting subtotal** * The calculated subtotal is displayed in the **Line Amount** field of the *Begin-Total* and/or in the *End-Total* comment lines. * The overall discount percentage for the block is also calculated and displayed. :::note Example |Type|Grouping|Description|Line Amount|Line Discount %|Formatting|Print line| |:--|:--|:--|:--|:--|:--|:--| |Comment|Begin-Total|Software Modules|5.500,00|5,00|Bold|Yes| |Item||Modul A|3.000,00|5,00|Normal|Yes| |Item||Modul B|2.500,00|5,00|Normal|Yes| |Comment|End-Total|Software Module|5.500,00|5,00|Bold|No| |Comment||*"Blank Space"*|||Normal|Yes| |Comment|Begin-Total|Implementation|4.200,00|0,00|Bold|Yes| |Item||Consulting|3.000,00|0,00|Normal|Yes| |Item||Development|1.200,00|0,00|Normal|Yes| |Comment|End-Total|Implementation|4.200,00|0,00|Bold|No| In this example, the two Begin-Totals are printed with the subtotal and the items. The End-Totals are not printed. A blank line is printed between the two blocks to clearly separate them from each other. ::: ## Key rules and system behavior ### Calculation rules * What is summed up? The total amount and discount amount of all Item, Resource, G/L Account, and Fixed Asset lines that fall between the *Begin-Total* and *End-Total* lines. * Lines not taken into account Other comment lines (as well as other subtotals and Bundle lines) are ignored in the subtotal calculation. * Auto-update Any change within the block (deleting a line, changing a quantity/price, or adding a new line) will automatically trigger a recalculation of the subtotal in the boundary lines. * Subscription Items If the option *Exclude Price/Discount/Amount* is selected in the **Subscription Item in Bundle** field in **Sales & Receivables Setup** (in *Bundle* tab), subscription items (i.e., items for which *Subscription Item* is selected in the **Subscription Option** field) are not included in the subtotals. * Alternative and Optional positions On Sales Quotes, lines marked via **DYCE IT-Business Toolkit**'s [Alternative and Optional Positions](/docs/ibt/alternative-optional-positions.md) feature are excluded from the block subtotal the same way. *Begin-Total* and *End-Total* lines themselves can never carry this marking. * Nested Subtotals A new subtotal block (*Begin-Total*) can be started, before closing the previous one with an *End-Total*. The *Begin-Total* will automatically find the corresponding *End-Total* in the same level. :::note Example: Nested Subtotals |Type|Grouping|Description|Line Amount|Line Discount %|Formatting|Print line| |:--|:--|:--|:--|:--|:--|:--| |Comment|Begin-Total|Software|9.700,00|0,00|Bold|Yes| |Comment|Begin-Total|Modules|5.500,00|0,00|Bold|Yes| |Item||Modul A|3.000,00|0,00|Normal|Yes| |Item||Modul B|2.500,00|0,00|Normal|Yes| |Comment|End-Total|Module|5.500,00|0,00|Fett|No| |Comment|Begin-Total|User|4.200,00|0,00|Fett|Yes| |Item||BC User|3.000,00|0,00|Normal|Yes| |Item||Modul User|1.200,00|0,00|Normal|Yes| |Comment|End-Total|User|4.200,00|0,00|Fett|No| |Comment|End-Total|Software|9.700,00|0,00|Bold|Yes| In this example, a *Begin-Total* is followed by another *Begin-Total*. Both *Begin-Totals* automatically find their corresponding *End-Total*. ::: ### Printing the subtotal The subtotals and their amounts are printed depending on **Print Line** and **Print Quantity Only**. * Use the **Print Line** field in the comment line to control printing: * Yes: The comment text is printed. * No: The line is not printed. This is used to hide the *footer line*. * Use the **Print Quantity Only** field in the comment line to control printing: * Yes: The line amount and discount are not printed in the subtotal. This is used to use the *Begin-Total* as a *header line*. * No: The line amount and discount are printed in the line. * Formatting: The selected formatting is applied to the subtotal. ### Setup The option field **Print Sub-Total** in **Sales & Receivables Setup** (in *Bundle* tab) is used to print the subtotals. * *Both*: **Print Line** field is automatically set to *Yes* in both *Begin-Total* and *End-Total* lines. * *Begin-Total*: **Print Line** field is automatically set to *Yes* in *Begin-Total* lines. In *End-Total* lines, it is set to *No*. * *End-Total*: **Print Line** field is automatically set to *Yes* in *End-Total* lines. In *Begin-Total* lines, it is set to *No*. ### Copy documents The subtotal blocks are maintained and recalculated whenever a sales document is copied or posted. This ensures accuracy when: * Make Order (quote >> order) * Invoicing (order >> invoice or quote >> invoice) * Creating a credit memo * Archiving documents --- ## Supported Layouts # Supported layouts The output (print) of content created via **DYCE Easy Bundle Seller** can be done either via WORD layout or via RDL layout. Therefore, the app comes with two additional layouts for each of the following reports. These can be identified by the extension name **DYCE Easy Bundle Seller**. * Sales - Quote (1304) * Order - Confirmation (1305) * Sales - Invoice (1306) * Sales - Credit note (1307) For more information on handling layouts, see this part of the Microsoft documentation. ## Notes about layouts The additional layouts are based on the standard layouts for the respective reports and are only extended to process content created via **DYCE Easy Bundle Seller**. While it is possible to use these out-of-the-box, it is usually the case that users use custom layouts. This is the real purpose of the additional layouts. It is very easy to identify the enhancements compared to the standard layouts and to transfer them to the customized layouts. For more details on this, please refer to the [next section](#notes-for-developers) and also the [Microsoft documentation](https://learn.microsoft.com/en-us/dynamics365/business-central/ui-get-started-layouts?tabs=copy). ## Notes for developers This section targets developers who want to transfer the extensions of the standard layouts, which were created using **DYCE Easy Bundle Seller** as an example, to customized layouts. ### Example: create new sales quote layout **DYCE Easy Bundle Seller** extends the Sales line with fields to control the line printout. Therefore, a report extension for the standard Sales Quote extends the dataset for the integration of formatting and bundles that can be used in a customized layout. This example describes how to use the standard RDL and WORD layout for Sales Quotes and extend it with formatting and bundle features for the Sales Quote line. #### RDL Layout * The standard RDL layout named "StandardSalesQuote.rdlc" can be copied from the base app and used as a basis for an extension or an already customized layout can be used. * Optional: The file extension can be changed to *.rdl in order to support editing with Microsoft Report Builder. * The integrated layout from the app **DYCE Easy Bundle Seller** should be downloaded as a model for changes to be made in newly created layout. * To do this, open the Report Layouts page in Business Central. * Find the report with ID 1304. * Locate the report layout for report 1304 named "./RDLCLayouts/DYCEEBSSalesQuote.rdl". * The layout can be exported using the respective action. * Both the newly created layout and the layout integrated in the app **DYCE Easy Bundle Seller** should be opened using Microsoft Report Builder or Visual Studio. * Delete the tablix control named "LinesTable" in the newly created layout. * Copy the tablix control named "LinesTable" from the layout used in the app **DYCE Easy Bundle Seller** and paste it into the newly created layout. * The newly created layout can either be integrated into the application that contains the customizations or imported from the Customer Report Layouts page within Business Central. #### WORD Layout * The standard Word layout named "StandardSalesQuote.docx" can be copied from the base app and used as a basis for an extension or an already customized layout can be used. * The integrated layout from the app **DYCE Easy Bundle Seller** should be downloaded as a model for changes to be made in newly created layout. * To do this, open the Report Layouts page in Business Central. * Find the report with ID 1304. * Locate the report layout for report 1304 named "./WordLayouts/DYCEEBSSalesQuote.docx". * The layout can be exported using the respective action. * Both the newly created layout and the layout integrated in the app **DYCE Easy Bundle Seller** should be opened using Microsoft Word. * Delete the content control containing the line fields in the newly created layout. * Locate the line printout in the layout used in the app **DYCE Easy Bundle Seller** and replicate the table in the newly created layout. * The newly created layout can either be integrated into the application that contains the customizations or imported from the Customer Report Layouts page within Business Central. --- ## Continuous Texts # Long texts and editor With **DYCE Happy Texts** it is possible to use long texts at different places in Business Central and also to print them. Images within the text are also supported. An editor is available for the creation of long texts. Here texts can not only be created, but also formatted. Long texts and images can be used in the following places: * Pre- and post-texts in Sales Quotes * Pre- and post-texts in Sales Orders * Extended description in Sales line * Extended description in master data (items, catalog items, resources) In addition, [text templates](/docs/ht/text-templates.md) that also support long texts and images can also be used in the places mentioned. They can also be edited using this editor. ## Paragraph and character formats The editor allows to create continuous texts including bulleted lists or numbered lists. The texts can be displayed in bold, italic and underlined. For further support, paragraph and character formats are offered to the user for selection, with which different fonts, sizes and line spacing can be realized. These different paragraph styles are stored system-wide in the [setup](/docs/ht/setup.md) for **DYCE Happy Texts**. Here you can define the desired formatting by means of an adaptation of the internet standard *Cascading Style Sheets* (CSS). A default is delivered with **DYCE Happy Texts**, which can be adapted to the company-specific requirements. In this way, on the one hand, a uniform display of texts is ensured, and on the other hand, it is guaranteed that the formats used can also be output via the print documents. :::info Specialty regarding RDL layout For technical reasons, RDL does not support all HTML tags that can be entered via the editor. Specifically, text highlighting and tables cannot be output with an RDL layout. ::: ## Pre- and post-texts in Sales documents Pre- and post-texts can be entered in Sales Quotes and Orders. A click on the AssistEdit for the fields **Header Text (Preview)** and **Footer Text (Preview)** opens the corresponding editor. The fields are displayed in the *General* fast tab. They contain the first part of the respective text and display it unformatted. The creation of pre- and post-texts can be [automated](/docs/ht/setup.md#automatic-pre--and-post-texts) to the extent that defined standard texts are used when a quote or order is created. ## Extended description A multilingual *extended description* can be stored in the master data for items, catalog items and resources (in the form of a text template). This [text template](/docs/ht/text-templates.md) for the extended description can be opened via the **Extended Description Exists** field and the content can be displayed via the **Contents** action. In addition to a description (including images), content for several languages and a date-based validity can also be defined here. In the Sales line, the **Extended Description (Preview)** field displays the first part of the extended description (unformatted). Clicking on the AssistEdit related to this field will open the editor, as well as via the **Extended Description** line action. The Extended Description is passed from one sales document to the next (e.g., from quote to order). :::info Transfer of pre- and post-texts Only when converting a quote to an order, the pre- and post-texts are transferred to the order. In all other constellations this is not the case. The Extended Description, on the other hand, is always transferred. ::: ## Output With **DYCE Happy Texts** additional layouts for the standard reports are provided. In these, the extended description is output after the descriptions of the lines and related text modules. For more information on layouts and developer notes, please refer to [this](/docs/ht/supported-layouts.md) part of the DYCE documentation. --- ## Unformatted texts Besides displaying formatted long texts and images, the editor included in **DYCE Happy Texts** is also used to display unformatted texts. These are for example the contents of the **[Report Configurations](/docs/general/essentials/report-configuration.md)** or the **[description of Time Recordings](/docs/pb/time-recording.md#create-time-recordings)**. For more information on the topics above, please follow the respective links. --- ## Setup(Ht) # Setup of DYCE Happy Texts **DYCE Happy Texts** does not necessarily require any special setup. However, a default template (Cascading Style Sheet - CSS) for [paragraph and character formats](/docs/ht/continuous-texts.md#paragraph-and-character-formats) is part of the delivery. This allows you to define the formatting options available in the editor. The CSS can be managed via the **DYCE Happy Texts Setup** page. If no CSS is available (**CSS imported** = *No*), the default template can be set using the **Set Default CSS** action. To change the contents of the CSS, you can either edit it directly or export it and then import it again after making the desired changes. ## Automatic pre- and post-texts Pre- and post-texts can be inserted automatically in Sales documents. In the **Sales & Receivables Setup**, in the *Text Templates* fast tab, the fields **Default Header Text Quote** and **Default Footer Text Quote** or **Default Header Text Order** and **Default Footer Text Order**, specify the defaults for texts to be used. This facility is optional. The text templates are transferred to the document as soon as the Contact or Document No. is filled in and the language code for the document is known. The contents of the text templates are determined on the basis of the language code and the validity date. ## Allow HttpClient Requests The full functionality of **DYCE Happy Texts** is only ensured if **HttpClient requests** are permitted (see also [here](/docs/ht/setup.md#allow-httpclient-requests)). The layout to be printed is transferred to a web service, which takes over the rendering and then returns it to Business Central. In the **Extension Management**, the **Extension Settings** of the app can be opened by clicking on the name of the app. Here **Allow HttpClient Requests** must be set to *YES*. :::info Error message when printing The following error indicates that **Allow HttpClient Requests** for **DYCE Happy Texts** is not activated: *The request was blocked by the runtime to prevent accidental use of production services.* ::: ## Handling layouts and hints to developers **DYCE Happy Texts** includes additional layouts (WORD and RDL) for the relevant standard reports from Business Central. These layouts are based on the standard layouts for the relevant reports. They can either be used out-of-the-box or are used to apply the relevant changes to the deployed (custom) layouts. For more information on layouts and notes for developers, please refer to [this](/docs/ht/supported-layouts.md) part of the DYCE documentation. :::info Rendering the report output Rendering the output of the report layouts including content created via **DYCE Happy Texts** is done using an external function call. ::: ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCEHTSALL (DYCE Happy Texts Read)** This permission set can be assigned to all users. It contains read-only permissions to use text templates. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCEHTEDIT (DYCE Happy Texts Edit)** This permission set is for power users who should be able to create and edit text templates. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCEHTSADMIN (DYCE Happy Texts Admin)** This permission set is designed for administrators and power users who should additionally be able to import and export stylesheets (CSS). The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information on permission sets, see this part of the Microsoft documentation. --- ## Supported Layouts(Ht) # Supported layouts The output (print) of content created via **DYCE Happy Texts** can be done either via WORD layout or via RDL layout. Therefore, the app comes with two additional layouts for each of the following reports. These can be identified by the extension name **DYCE Happy Texts**. * Sales - Quote (1304) * Sales - Confirmation (1305) * Sales - Invoice (1306) * Sales - Credit Memo (1307) For more information on handling layouts, see this part of the Microsoft documentation. ## Notes about layouts The additional layouts are based on the standard layouts for the respective reports and are only extended to handle content created via **DYCE Happy Texts**. Although it is possible to use them out-of-the-box, it is usually the case that users use customized layouts. This is the real purpose of the additional layouts. It is very easy to identify the enhancements compared to the standard layouts and to transfer them to the customized layouts. For more details on this, please refer to the [next section](#notes-for-developers) and also the [Microsoft documentation](https://learn.microsoft.com/en-us/dynamics365/business-central/ui-get-started-layouts?tabs=copy). ## Notes for developers This section targets developers who want to transfer the extensions of the standard layouts, which were created using **DYCE Happy Texts** as an example, to customized layouts. ### Example: create new sales quote layout A report extension for the standard sales quote in the **DYCE Happy Texts** app has been extended with fields used to display HTML content, thus preparing the dataset for the integration of HTML content in a customized layout. This example describes how to use the standard RDL and Word layout for Sales Quotes and extend it with header texts, footer texts and extended description for the Sales Quote line. #### RDL Layout * The standard RDL layout named "StandardSalesQuote.rdlc" can be copied from the base app and used as a basis for an extension or an already customized layout can be used. * Optional: The file extension can be changed to *.rdl in order to support editing with Microsoft Report Builder. * The integrated layout from the app **DYCE Happy Texts** should be downloaded as a model for changes to be made in newly created layout. * To do this, open the Report Layouts page in Business Central. * Find the report with ID 1304. * Locate the report layout for report 1304 named "./RDLCLayouts/DYCEHTSalesQuote.rdl". * The layout can be exported using the respective action. * Both the newly created layout and the layout integrated in the app **DYCE Happy Texts** should be opened using Microsoft Report Builder or Visual Studio. * Copy the tablix control named "DYCEHtmlForRdlHeader_Table" from the layout used in the app **DYCE Happy Texts** and paste it in the newly created layout before the tablix for displaying the lines. * Copy the tablix control named "DYCEHtmlForRdlFooter_Table" from the layout used in the app **DYCE Happy Texts** and paste it in the newly created layout at the end of the document. * Locate the the last two lines from the tablix named "LinesTable" in the layout used in the app **DYCE Happy Texts** and replicate the changes made for those two lines in newly created layout. * The newly created layout can either be integrated into the application that contains the customizations or imported from the Customer Report Layouts page within Business Central. #### WORD Layout * The standard Word layout named "StandardSalesQuote.docx" can be copied from the base app and used as a basis for an extension or an already customized layout can be used. * The integrated layout from the app **DYCE Happy Texts** should be downloaded as a model for changes to be made in newly created layout. * To do this, open the Report Layouts page in Business Central. * Find the report with ID 1304. * Locate the report layout for report 1304 named "./WordLayouts/DYCEHTSalesQuote.docx". * The layout can be exported using the action. * Both the newly created layout and the layout integrated in the app **DYCE Happy Texts** should be opened using Microsoft Word. * In the newly created layout add a new content control named "DYCEHtmlForWord_Header_Placeholder" before the Table used for displaying the lines analog to the the layout used in the app **DYCE Happy Texts**. * In the newly created layout add a new content control named "DYCEHtmlForWord_Header_Placeholder" at the end of the document analog to the the layout used in the app **DYCE Happy Texts**. * Locate the the nested repeater content control named "DYCEHtmlForWord_Line_Placeholder" in the layout used in the app **DYCE Happy Texts** and replicate the changes made for this line in newly created layout. * The newly created layout can either be integrated into the application that contains the customizations or imported from the Customer Report Layouts page within Business Central. --- ## Text Templates # Text templates In addition to the manual entry of long texts in the Sales line and the storage of extended descriptions in the master data (for items, catalog items and resources), text templates can be freely defined. They can also be used as automatic defaults for [pre- and post-texts](/docs/ht/setup.md#automatic-pre--and-post-texts) in Sales documents. Text templates contain already formatted text and images. They can be adapted or extended as required. They also offer the option of using [placeholders](#use-of-placeholders), which are then automatically replaced with specific values at a later date. ## Create and edit text templates In the **Text Templates** page, these can be created and customized and their use can be controlled by defining filters. The **Area** is used as a default for the scope of application of the text templates, as the **Table ID** and any table filters are preset here. Basically, the areas *Sales*, *Sales Quote*, *Sales Order*, *Item*, *Resource*, *Catalog Item* and *User-defined* are provided, whereby the master data related areas *Item*, *Resource* and *Catalog Item* are hidden by default. When selecting a text template, the table ID is automatically filtered depending on the context. In addition to the **Table ID**, the use of the text template can be restricted via **Table Filters**. To do this, the **Filter** action is used to open a filter page matching the table, in which the desired table filters are defined. The **Contents** action is used to access the actual content of a text template. This can consist of several texts, e.g. to map several languages. In addition, a validity period (via **Starting Date** and **Ending Date**) of a content can be defined here. Content can also be opened via the **Contents Count** field on the **Text Templates** page. The validity period of a content is optional. If nothing is specified here, it is not subject to a time limit. However, several validity periods can be defined, e.g. for different content of the same text template at certain times. The respective text is entered or edited with the **Edit Text** action. This is done using the [editor](/docs/ht/continuous-texts.md) from **DYCE Happy Texts**. :::info Restrict text templates for specific languages It is only necessary to specify a language code for the content of a text template if the content is only to be entered or valid for a specific language. If no language code is specified, the content is valid for all languages. ::: ## Select a text template In addition to the table ID, other table filters are also taken into account when the user manually selects suitable text templates. If several text templates are found after applying these filters, they are displayed in the order of the text template **Code**. ## Use of placeholders Placeholders can generally be used in all text templates. However, some places are more predestined than others, e.g. the Header Text of a Sales Quote or Order. They represent text content that is substituted in one of the following steps (see [Time of substitution](#time-of-substitution)): * The placeholder is replaced the moment the template is applied. * The placeholder is replaced during output (e.g. printing/PDF). Placeholders can control automatic numbering or call functions that generate text content. They can also represent system variables (such as the current date or user ID) or references to fields from the current record or from a referencing table. References to fields can be quite complex. For example, a call from the *Sales Header* can reference the salesperson's email address using the salesperson code assigned there. ### Time of substitution Whether the substitution of a placeholder takes place when a text template is *called* or only when the text is *output* is controlled by the use of curly or square brackets. **Placeholder in curly brackets** Placeholders in curly brackets (e.g. \{TIME}) are typically only (pre-)defined in text templates. If the template is used, e.g. automatically inserted as Header Text, such placeholders are immediately substituted. The placeholder is therefore replaced by the actual content when the template is inserted. * **Placeholders in square brackets** The contents of placeholders in square brackets (e.g. [TIME]) are only determined at the time of output, so that the current value is output. :::tip Examples for field references Fields are to be referenced in the Header Text of a Sales Quote. The current table is therefore the *Sales Header* (table 36). * **Example 1:** \{@152} shows the date for how long the quote is valid (field **Quote Valid To Date**) * **Example 2:** \{@2} outputs the number of the Customer who receives the products (field **Customer No.** or **Sell-to Customer No.**) ::: ### Variables as placeholders System variables and the *asterisk* can be used as variables for placeholders. The placeholder \{\*} triggers automatic numbering. The following system variables are also substituted: |System variable|is determined as| |:--|:--| |\*|non-numbered listing| |TODAY|Current system date| |TIME|Current system time| |WORKDATE|The workdate set by the user| |CURRENTDATETIME|Current system date/time| |USERID|User ID of the logged in user| |COMPANYNAME|Name of the company| ### Reference to the field of another table A reference can also be used to retrieve data from a field in another table based on the current record. To uniquely define the record in the target table, its primary key is required, among other things. The expression consists of three sections: First, the remote table is referenced, followed by the field to be returned and the primary key of this table. **Schematic structure:** \{\<@remote_table>;\\{\<@primary_key_of_remote_table>}} |String|Explanation| |:--|:--| |remote_table|the number of the table that can be determined using the *Page Inspection*, specified with leading @| |field_in_remote_table|the field number that can be determined using the *Page Inspection*, specified without leading @| |primary_key_of_remote_table|the primary key of the referenced table, specified with leading @| Note: If the key is made up of several fields, these are listed separated by comma. :::info Empty key value If the primary key field on the current record is empty at the time of substitution (for example, a Sales Header field that is only filled later in the document's lifecycle), the reference resolves to an empty value instead of an error - the same as when the referenced field itself is empty. ::: :::tip Examples of references to fields in other tables Fields are to be referenced in the Header Text of a Sales Quote. The current table is therefore the *Sales Header* (table 36). * **Example 1: *Output* telephone number of the salesperson** Exemplary: \[\<@SalesPerson/Purchaser>;\;\[@\]] Actual: \[@13;5053;\[@43]] Based on the table *Sales Header* (table 36), field **Salesperson Code** (field 43), the **Phone No.** (field 5053) is determined from the table **Salesperson/Purchaser** (table 13). Note: The telephone number is only replaced during output. * **Example 2: *Get* name of invoice recipient** Exemplary: \{\<@Customer>;\;\{@\}} Actual: \{@18;2;\{@4}} The name of the invoice recipient is retrieved from the **Name** field (field 2) of the **Customer** (table 18). The primary key under which the customer is found is determined from field **Bill-to Customer No.** (field 4) of the current record of the table *Sales Header* (table 36). Note: The invoice recipient is replaced directly when the text template is applied. ::: ### Functions as placeholders Functions can also be used as placeholders. The return value of the function is then inserted as text. Functions can be specified as placeholders in the following way: \{\#FUNCTIONNAME(PARAMETER 1,PARAMETER 2,...)} |String|Erläuterung| |:--|:--| |FUNCTIONNAME|Name of the desired function| |PARAMETER(S)|the parameters required to execute the function| Attention: There must be no spaces between the list of parameters! There is currently only one function available which replaces the salutation. The function **\#ContactSalutation(ContactNumber,Type)** is used to determine the salutation of a contact, for example. The **ContactNumber** parameter references the desired contact for the salutation, while the **Type** parameter controls the definition of the type of salutation. The values *For*, *Inf* and *Int* are permitted for formal, informal and internal salutations. :::tip Examples of functions in placeholders In all examples, the *Sales Header* (table 36) is used as the current table. * **Example 1: \{\#ContactSalutation(\{@5052},For)}** The function determines the formal salutation for **Sell-to Contact No.** (field 5052) from the current record. Please ensure that a formal salutation exists for the language code used in the contact. Otherwise, no formal salutation can be found in the documents and an error will occur. * **Example 2: \{\#ContactSalutation(\{@5052},Inf)}** This function call returns the informal salutation. Please ensure that an informal salutation exists for the language code used in the contact. Otherwise, no informal salutation can be found in the documents and an error will occur. ::: --- ## Alternative and Optional Positions In standard Business Central, every line on a Sales Quote counts toward the total and is carried over automatically once the quote becomes a Sales Order. This becomes a problem as soon as a quote needs to show a choice between alternatives (e.g. *Model A* vs. *Model B*) or an optional add-on (e.g. an extended warranty). Such lines should stay visible to the customer, but must not inflate the total or end up on the order by mistake. To solve this, **DYCE** introduces the **Label** field on Sales Quote lines, so a line can be marked as a regular position, an *Alternative*, or an *Optional* addition. Labeled lines stay visible on the quote and in print, but are excluded from every total and are skipped when the quote is turned into an order. ## Working with the Label field The **Label** field is only available on Sales Quote lines, and read-only on the Sales Quote Archive. It can be left *blank*, the default, for a regular position, or set to *Alternative* for an alternative choice, or *Optional* for an optional add-on. Setting **Label** to *Alternative* or *Optional* highlights the line while editing, making it easy to spot. In print, the line appears in italic instead, using the [Formatting](/docs/ebs/formatting.md) field. The **Unit Price** and **Line Amount** are still printed unchanged. Labeling a line immediately removes its amount from the quote total, from the subtotal of any [subtotal block](/docs/ebs/subtotals.md) it belongs to, and from the printed subtotal and total. When a quote is archived, the **Label** is copied as-is and becomes read-only there. Clearing the **Label** restores the line's normal styling (except on the bundle line, see [Bundles](#bundles-and-subtotals) below). :::info Subscription Items A line for a Subscription Item can also be labeled. Since such lines are already excluded from the quote total by Business Central, the **Label** has no additional effect on the total in this case, but it is still saved. ::: ### Make Order and Copy Document The **Make Order** action only transfers lines with a blank **Label** to the resulting Sales Order. *Alternative* and *Optional* lines are skipped entirely and never appear on the order; regular lines transfer unaffected. **Copy Document** behaves depending on the target: * Sales Quote to Sales Quote: the **Label** is copied as-is. * Sales Quote to any other document type (e.g. a Sales Order): the **Label** is dropped, since the field only has meaning on a quote. * Archived Sales Quote to Sales Quote: the **Label** is copied back from the archive. ### Bundles and Subtotals A [bundle](/docs/ebs/bundles.md) and its components are always labeled as a whole, never partially. Setting **Label** on the bundle line or on any single component applies the same value to the bundle line and all its components immediately, with a notification, and clearing it removes the **Label** from the whole bundle in the same way. If a line that already has a **Label** is added as a component to a bundle, its **Label** silently changes to match the bundle's. Deleting a bundle line also clears the **Label** on its former components, along with their grouping. The only difference from a regular line is that **Formatting** does not reset to blank here. Instead, it checks the **Bundle Line Format Style** field in [Sales & Receivables Setup](/docs/ebs/setup.md#sales--receivables-setup) and uses its default value, so the bundle keeps its uniform look. *Begin-Total* and *End-Total* lines of a [subtotal block](/docs/ebs/subtotals.md) can never carry a **Label**. Only regular lines and bundle lines can be marked as *Alternative* or *Optional*. Attempting to label a Begin-Total or End-Total line raises an error and leaves the field unchanged. A regular line inside a subtotal block can still be labeled like any other line, but a notification points out that both the block subtotal and the quote total will change. --- ## Import Calculation # Import of calculations This function can be used to import *calculations* or *configurations* from a source system into a Sales Quote or Sales Order. It is irrelevant whether the source system is an internal (sales-oriented) system or the system of a vendor, for example. A universal import reads the content from a file into an import table. Alternatively, the data can also be transferred to the import table via an interface. During subsequent processing, all items that do not yet exist are created during the import as catalog items and items and the quote/order lines are created. ## Importing a calculation {#importing-a-calculation} If a calculation is to be imported using a file, a [Data Exchange Definition](/docs/ibt/setup.md#data-exchange-definitions-for-calculation-import) is required. If this is defined, the import process is started in the sales offer via the action **Import Calculation** (action group *Prepare*). The page that opens asks for the Data Exchange Definition to be used and the import file and also provides an option to set a project reference (*Special Bid*) from the vendor. If the Data Exchange Definition maps a **Special Bid No.** per line from the import file, that value is kept, so one sales quote or order can contain several special bids; the **Special Bid No.** entered on the page only applies to lines without a value from the file. After successful import, the imported lines can be opened directly. Before subsequent [further processing](#process-imported-lines), an import indicator (**Type**) must be set in all lines on the **Imported Calculation** page. Lines that are not to be processed must be deleted. If the field **[Set default values for Calculation Import](/docs/ibt/setup.md#calculation-import)** is set to *YES* in the **Sales & Receivables Setup**, the system attempts to preallocate this field independently. :::info Pre-assignment of the import indicator The system proceeds as follows for automatic preallocation: * The *first* line containing a price is marked as *Main*. If the import contains several *Main* lines, the remaining main lines must be marked as such manually. * All further lines containing prices are marked as *Component*. * All lines *without* a price are marked as *Text*. These lines are saved on the document line of the main item and are taken into account when the line is processed further (see [Calculation texts](#calculation-texts)). ::: In addition, the system uses the **Manufacturer Item No.** to determine whether a matching catalog item already exists. If this is the case, it is entered directly in the corresponding field. Otherwise, the field remains empty and the catalog item is created in the next processing step. :::tip Default vendor of the supplier As the structure of the calculation or import file tends to differ from supplier to supplier, a separate [Data Exchange Definition](/docs/ibt/setup.md#data-exchange-definitions-for-calculation-import) must be created for each supplier. This also has the advantage that the vendor no. of the supplier does not have to be entered manually but can already be stored in the Data Exchange Definition as a [fixed value](/docs/pli/setup.md#fixed-values). ::: ### Process imported lines The next step is to process the imported lines. This is done by calling up the **Process** action. In addition to specifying the Vendor No. of the supplier (**Buy-from Vendor No.**), the fields **Vendor Item No.**, **Item Template Code** and **Unit of Measure Code** are required. If this information is incomplete, a corresponding error is displayed in the respective line. If new catalog items are required, these are created. Otherwise, the existing ones are used ([see above](#importing-a-calculation)). Document lines are created for all *Main* or *Component* lines. An item is automatically created for each catalog item based on the item template. ### Calculation texts Each text line is saved as a *Calculation Text* and linked to the document line of the chosen **Main** item, since multiple **Main** lines can be selected during import. In addition to the description, the **Manufacturer Item No.** and **Quantity** are taken into account. The texts can be called up via the field of the same name in the document line or via the **Sales Line Details** fact box. Furthermore, the texts are also considered during further processing of the document line, e.g. when creating a Purchase Order or when posting or archiving the document. In addition, they are printed in a separate section in the Purchase Order and Sales documents. --- ## Customers & Contacts # Linking Contacts with Customers and Vendors Contacts are linked to Customers (and/or Vendors) via so-called *Business Relations*. For details on how business relations work, please refer to this part of the Microsoft documentation. ## Fact boxes for transactions and documents In the contact overview and card, there are two fact boxes that represent the sales history of the contact. The fact box **Sell-to Sales History** refers to all transactions in which the contact is included as a *sales recipient* (i.e. the one to whom, for example, the order was *sold*). The fact box **Bill-to Sales History** shows all transactions in which the contact is included as *invoice recipient*. Clicking on the respective tiles will open the records behind them. While the info box regarding the invoice recipient *can* only refer to the transactions of the linked **Customer**, there are two special features regarding the sales recipient: * The tiles for the **Open Tasks** and the **Open Sales Opportunities** show the transactions by their respective *contacts*. * Since a business relations between the contact and a customer is not *necessary* for a quote, but *may* exist, there is a case distinction regarding the filter. * If there is a Business Relation to a Customer, the tile for the company contact will show *all* offers of the company, the tile for the person contact will show only the offers for this person. The offers are filtered based on the related Customer No. (via the **Sell-to Customer No.** field). * If there is no Business Relation to a customer, the tile always shows only the offers of the respective contact. In this case, the offers are filtered based on **Sell-to Contact No.**. In the customer overview and card, there is only the fact box that shows the sales history of the *sales recipient*. ## Creation of Sales Quotes without a customer To create a quote to a prospective customer, it is not necessary to create him as a customer in Financial Accounting at this stage. For this purpose, a contact is sufficient, which is used together with a suitable customer template. Only when converting a sales quote into a sales order, the Business Relation to a customer is mandatory required in the contact. The customer template contains all the necessary information, such as Business and Gen. Prod. Posting Groups, payment terms, but also information on tax, which are necessary for the creation of an offer. These specifications are stored in the customer templates, which can also be opened via the search (*Alt+Q*). Here also different sample templates for other countries/regions, currencies or area codes etc. can be deposited for selection. The template that suits a prospect can thus be quickly selected when creating quotes as well as when creating a customer based on a contact. ## Document Sending Profiles Via **[Batch Sending Documents](/docs/general/essentials/batch-sending-documents.md)** it is controlled whether the settings defined at the customer are used for batch sending of posted documents or whether the standard dialog is displayed. For the default setting *Use customer's setup* no dialog is displayed. --- ## Licensee # Licensee address mandatory In industries such as software distribution or licensing, vendors often require detailed information about the End Customer, not just the reseller. This typically includes the **Contact Person**, **Email Address** and **Company Name**. To support this, **DYCE** allows this key data to be entered on the Sales Order and it is automatically transferred to the connected Purchase Order. This supports flexible workflows commonly found in sales and procurement, where the required data can be entered either before the Purchase Order is created or later during the process. The **Licensee Required** field on the **Item Card** (in the *Prices and Sales* FastTab) specifies whether licensee information will be required during the Sales and Purchase process. ## Documents and process When an item with **Licensee Required** set to *YES* is added to a Sales Quote or Order or a Purchase Order, a new tab **Licensee** becomes available. This tab contains the fields **Contact Name** and **Email**. :::info Notification If at least one item with **Licensee Required** set to *YES* is added to a sales or purchase document, and any of the required **Licensee** fields (**Contact Name** or **Email**) is missing, a notification is displayed. ::: The fields on the **Licensee** tab are not editable directly. By clicking any of these fields, a separate **Licensee** page opens, allowing the user to enter values for the fields shown on the tab, as well as additional related fields (**Address**, **City**, **Post Code**, **Country/Region Code**, and **Phone No.**). All fields are editable and initially populated based on the customer selected on the page. :::tip Accessing the Licensee page The **Licensee** page can also be accessed via the **Licensee** action on the following documents: Sales Quote, Sales Order and Purchase Order. ::: When a **Licensee Required** item is added to a Sales Quote, entering information in the **Licensee** tab is not mandatory immediately, and the **Make Order** action can be executed without. However, the resulting Sales Order cannot be shipped unless the fields **Contact Name** and **Email** are filled in. If the information is already entered on the **Licensee** page in the Sales Quote, it is automatically transferred to the newly created Sales Order. ### Create Purchase Order :::info Integration with other DYCE features The feature is also compatible with the **[Create Connected Purchase Orders](/docs/ibt/sales-related-procurement.md)** functionality from **DYCE IT-Business Toolkit**, as well as the **[Create Warehouse Shipment (Interactive)](/docs/msp/partial-shipment-and-purchase.md)** feature available in **DYCE Managed Service Providers**. ::: When the **Create Connected Purchase Order** or **Create Warehouse Shipment (Interactive)** action is called on a Sales Order, and at least one line contains an item with **Licensee Required** set to *YES*, all relevant information from the **Licensee** page is transferred to the corresponding fields on the Purchase Order. These actions can still be executed even if **Contact** or **Email** have not been entered. In such cases, a confirmation dialog is displayed before proceeding. When creating a [new](/docs/msp/partial-shipment-and-purchase.md#create-purchase-orders) Purchase Order or [extending](/docs/msp/partial-shipment-and-purchase.md#extend-purchase-order) an existing one via the [Purchase Requisition](/docs/msp/partial-shipment-and-purchase.md#central-overview-for-purchase-orders) page, the use of **Licensee** details (**Contact Name** and **Email**) affects how Warehouse Shipment Lines are combined in one Purchase Order. The [existing criteria](/docs/msp/partial-shipment-and-purchase.md#create-purchase-orders) are extended with an additional condition: * If **Contact Name** or **Email** (from Sales Line) differ between Purchase Order and Sales line, a new Purchase Order is created. :::note Archiving Licensee details are archived in the corresponding fields of the Sales Quote Archive, Sales Order Archive, and Purchase Order Archive, and can be restored in alignment with standard Business Central behavior. ::: If a Purchase Order is created using **Create Connected Purchase Order** or **Create Warehouse Shipment (Interactive)**, and the information on the **Licensee** page is later changed or updated, the connected Sales Order is automatically updated when the Purchase Order is received. In addition, if **Licensee** details are available, they are always printed in a separate section on Sales and Purchase documents. --- ## Margin Calculation # Margin calculation In addition to the usual procedure of transferring the sales price of an item from its master data to the Sales line, it is also possible to calculate it using a percentage margin. This is often used for specific trade items (e.g. hardware) for which no sales price is available (e.g. if the items were created using **[Calculation Import](/docs/ibt/calculation-import.md)**) or the margin is more important than the absolute sales price. Basically, from a calculation perspective, the margin is one of the most important prerequisites for making a profit in a trade-oriented company. ## Different calculation bases The margin represents the difference between the selling price and the cost price and is therefore usually expressed as a percentage. **DYCE IT-Business Toolkit** provides two different methods for the calculation: the *trade margin* or the *markup*. Which method is used is determined via the **[Sales & Receivables Setup](/docs/ibt/setup.md#sales--receivables-setup)**. A new field is available in the Sales line, with the field name dynamically following the above setup. Here, the percentage margin is calculated by the system as soon as a Sales line is created with the necessary information. The **Calculation Base** and the other details from the **Sales & Receivables Setup** are taken into consideration. In addition to the percentage margin, the absolute difference amount is also displayed as **Profit Margin (LCY)**. :::note Visibility In the lines in the Sales Quote, the **Trade Margin %** or **Markup %** field is displayed by default; in the lines in the Sales Order, the field is available but is not displayed automatically. It can be displayed by personalization. ::: ### Trade margin When entering or changing one of the fields **Unit Cost**, **Trade Margin %**, **Unit Price Excl. VAT** or **Profit Margin (LCY)**, the other fields are recalculated. :::info Example |Field|Value| |:--|:--| |Unit Cost|800| |Trade Margin %|20| |Profit Margin (LCY)|200| |Total|1,000| ::: ### Markup If you enter or change one of the fields **Unit Cost**, **Markup %**, **Unit Price Excl. VAT** or **Profit Margin (LCY)**, the other fields are recalculated. :::info Example |Field|Value| |:--|:--| |Unit Cost|800| |Markup %|20| |Profit Margin (LCY)|160| |Total|960| ::: --- ## Payment Plan # Payment Plans in Sales Orders **DYCE IT-Business Toolkit** has made significant changes regarding prepayments in the sales area. The terms ***Prepayments*** and ***Down Payments*** will be used interchangeably throughout the remainder of this documentation. :::info Sales tax The implementation is currently based on the latest requirements of German tax law. The tax is shown in the prepayment invoice, but this is only due when the payment has been received. The tax is then automatically posted when the payment is received. For basics on how prepayments work, please refer to this part of the Microsoft documentation. ::: ## Master data for Prepayment Setup Before starting the master data setup, some basic decisions need to be made. The basic system setup can be used to control whether: * the tax shown on the prepayment invoice/credit memo should be posted as unrealized and therefore not yet due, * a partial or final invoice can be created, even if there is not yet an incoming payment, or * a separate document number range should be used for the Prepayment Invoices / Credit Memos posted. The setup is explained in this part of the Microsoft documentation. ### General Ledger Setup In General Ledger Setup, the **Prepayment Unrealized VAT** field (in the *General* fast tab) controls how (unrealized) VAT should be posted when posting a Sales invoice. For more details on Prepayments incl. instructions on how to set up the VAT Posting Setup can be found in [this](#unrealized-vat) part of the DYCE documentation. ### Sales & Receivables Setup In the fast tab *Number Series* the number series for the posted Prepayment Invoices or Prepayment Credits Memos are stored. Thus, separate number series can be used for prepayment documents. :::note Number Series If the same number series should be used for Prepayment Invoices and Credit Memos as for regular sales documents, the same number series can be stored here. ::: ### Further options for Prepayment Both for customers (in the *Payments* fast tab) and for items (via *Related / Sales / Prepayment Percentages*), fixed percentages for down payments can be stored. These default values are always used automatically when a new sales document is created for the corresponding customer. However, the following should be noted: The **Prepayment %** field in the customer is transferred to the sales document field of the same name when the Sales Order is created. This means that a general Prepayment Percentage is defined at the Customer, which is basically used for all sales to this Customer. On the other hand, it is possible to define in the item (independently of the customer deposit) that when this item is used in the sales document, a certain down payment is always due. This deposit is made via the Item Card (see above) in the **Prepayment Percentages** page and can - as in the Sales Price table - apply to certain groups, but also to certain individually listed Customers. The defaults on the item override the defaults on the Customer. This means that if a Customer has a general Prepayment Percentage set and purchases an item that also has a Prepayment Percentage set, the sales document will take over the *general* percentage, but the Sales Line will use the Prepayment Percentage from the item. Both default values can be adjusted manually. When the down payment invoice is posted, the value from the Sales Line wins. :::info Priorities for Prepayment Percentages The value in the **Prepayment Percentage** field on the Customer can contain a Prepayment Percentage that applies to all orders for that Customer, regardless of the items or Services in the Sales Order lines. If, on the other hand, prepayments are to be set up for individual items, it is recommended that the **Prepayment Percentage** field on the customer be left blank and instead the Prepayment Percentages be entered in the **Prepayment Percentages** page of the Item Card. Both types together may lead to an undesired result. ::: ### Unrealized VAT In Business Central standard it is possible to initially post the VAT from Prepayment Invoices for which payment has not yet been received as unrealized VAT and to automatically re-post it as VAT when the payment is posted. In this way, the VAT will only be included in the VAT statement in the month in which the payment is received. If this is desired, the indicator in the **Unrealized VAT** field in the [General Ledger Setup](#general-ledger-setup) (fast tab *General*) must be set to *YES*. In addition, when setting up the **VAT Posting Setup**, the **Unrealized VAT Type** field is used to control what portion of the VAT should be reposted from *Unrealized VAT* to *realized VAT* if partial payments are received to clear the Prepayment Invoices. In the field **Sales VAT Unreal. Account**, the account to which the unrealized VAT is to be posted must be specified. For further explanation of Setting Up Unrealized VAT and Posting Methods for VAT, please refer to the parts of the Microsoft documentation mentioned here. ## Sales process with prepayment In the next sections, the specifics within the sales process regarding prepayments will be explained in more detail. ### Sales Order After the Sales Order is created, the **Prepayment %** rate and the payment condition (in the **Prepmt. Payment Terms Code** field) for the prepayment invoice are stored in the *Prepayment* fast tab. The value entered in the **Prepayment %** field is then applied to all lines. :::info Multiple Prepayment Percentages The **Prepayment %** field remains empty if different percentages or the absolute values per Sales Line are to be used. In this case, the deposit is done directly in the Sales Order lines (see [next section](#document-lines)). ::: ### Document lines In the Sales Order lines, the **Prepayment %** rate or the **Prepmt. Line Amount Excl. VAT** can be entered (or overwritten). The **Prepmt. Amt. Inv. Excl. VAT** shows the amount already invoiced for each line (the field is not editable). In the **Prepmt. Amt. to Deduct Excl. VAT** field, the amount to be deducted is first automatically calculated and entered based on the quantity to be invoiced. This amount can be changed manually, but the system ensures that the prepayment amount to be deducted cannot be entered higher than the remaining amount of the line. If a partial invoice has been created, the **Prepmt. Amt. Deducted Excl. VAT** amount will be shown in the corresponding field. It is possible to create multiple Prepayment Invoices for one Sales Order. After a Prepayment Invoice has been created, the order will be marked accordingly via the **Prepayment Invoices for Cust. Ledger Entries exist** field (see also section [Prepayment Customer Ledger Entries](#prepayment-customer-ledger-entries)). ### Create Prepayment Invoices After all information has been set up in the Sales Lines, the **Create Prepayment Invoice** action (via *Actions / Payment Plan*) will create an unposted prepayment invoice. If the **Post Invoice** checkbox is selected, the Prepayment Invoice will be created and posted immediately. The unposted invoice can be opened and viewed via the call **Prepayment Invoices** (via *Related / Prepayment*) and, for example, the text information can still be changed. In the Prepayment Invoice lines, the G/L account stored (field **Sales Prepayments Account** in the **General Posting Setup**) is addressed in each invoice line, but the description texts from the corresponding Sales Order lines are transferred to the unposted invoice. This allows the user to see exactly which line items are being invoiced as prepayments. ### Prepayment Customer Ledger Entries When the Prepayment Invoice is posted, Prepayment Customer Ledger Entries are created. These can be viewed in the Sales Order via the call **Prepayment Customer Ledger Entries** (via *Related / Prepayment*) filtered for the respective order. At a glance, all Prepayment Invoices and Prepayment Credit Memos are displayed here with the related line amounts in document currency and in local currency (LCY) of the client. If the **Closed Ledger Entry** field is checked, this invoice item has already been paid. A complete overview of all Prepayment Invoices and Credit Memos in the system can be obtained by searching for *Prepayment Ledger Entries* (*Alt+Q*). ### Post incoming payment When posting the incoming payment for the down payment, there are no special features to be considered. Depending on the setting in the **VAT Posting Setup**, the incoming payment will then automatically transfer the tax portion from the **Unrealized VAT** account to the **Realized VAT** account. ### Partial and final invoice on a Sales Order In case of a partial or final invoice of the Sales Order lines, the prepayment amount already made will be deducted. If at this time the payment receipt for the Prepayment Invoice has not yet been posted, a corresponding note will be issued - however, it is still possible to create a final invoice. In the case of partial invoicing (adjustment of the quantity in the **Qty. to Invoice** field), the prepayment amount in the **Prepmt. Amt. to Deduct Excl. VAT** field is also automatically adjusted accordingly. It is also possible to change the (automatically) entered default value in the **Prepmt. Amt. to Deduct Excl. VAT** field. However, it is ensured that in the case of a partial invoice, only so much can be deducted at any one time that the prepayment amount is not higher than the actual invoice amount in the final invoice. :::info Prepayments in the final invoice If one or more prepayment invoices are created for an order, they will be taken into regards in the final invoice. Here, all prepayments are summarized *per order line*. The final invoice cannot be created as long as the prepayments have not been invoiced. ::: ### Create Prepayment Credit Memo If the Prepayment Invoice was created incorrectly, a Credit Memo can be used to revoke it. The **Create Prepayment Credit Memo** function (via *Actions / Payment Plan*) will re-credit all calculated prepayments that have not yet been deducted in a partial invoice. In the fast tab *Options*, a clearing can be made with the previously posted down payment invoice, so that the posting of the credit memo also clears the open invoice item at the same time. If the **Post Credit Memo** checkbox is selected, the credit memo is posted immediately by clicking OK. If, on the other hand, the indicator is not set, an unposted credit memo will be created (analogous to invoice creation), which can still be viewed before posting and/or in which text lines can still be entered if necessary. :::info Currencies If a currency is used and different currency exchange rates apply per invoice / partial invoice / prepayment, a retroactive currency exchange rate adjustment is carried out and posted with the final invoice for all invoices / credit memos issued. ::: ## Sales Process with Payment Plans In addition to manual prepayments, DYCE offers the option to set up a Payment Plan. This is a preliminary stage to the prepayment in order to be able to store the negotiated payment plan data in advance in the system. There are separate Payment Plan Steps for handling Payment Plans. Each stage can be applied to one or more Sales Lines. The Payment Plan feature in **DYCE IT-Business Toolkit** includes: * Creation of Payment Plans for Sales documents * Multiple payment levels with assignment to different Sales Lines * Same handling regarding billing - no matter if using a Payment Plan or manual prepayments :::warning Payment Plan If a Payment Plan is used, further processing must be done through it. It is not possible to mix manual prepayments and a Payment Plan within one Sales document. ::: ### Setting up a Payment Plan The distribution of Payment Plan Steps percentages to the related lines is always based on the line amount. Thus, the sales amount of the related lines serves as a criterion for the distribution of the prepayment amount to the Sales Order lines. There is no need to make any further settings regarding the Payment Plan, everything else is done directly in the Sales document. ### Using a Payment Plan in a Sales Order After a new Sales Order is created, the agreed Payment Plan is created directly in the document using the **Payment Plan** action (via *Related / Prepayments*). The Payment Plan can include one or more steps. Each Payment Plan step contains either a fixed amount (**Payment Amount** field) or a percentage (**Payment %** field) and must relate to a specific Sales Order line. The link to the Sales Order line is established using the **Select Sales Lines** action. In the **Payment Plan Sales Line Selection** page that opens, the link to the Sales Lines is made per line in the Payment Plan by selecting them. The selected lines are marked by the **Selected** field. At the same time, the **Lines attributed** field in the Payment Plan Steps indicates that Sales Lines are already assigned to that step. If multiple Payment Plan Steps of similar or the same content are entered, it is recommended to create the additional lines by copying them. This can be accomplished by using the **Copy Step** action. The Payment Plan Steps also contain additional fields with the following purpose: |Field|Meaning| |:--|:--| |Description|The text entered here will be copied as text in the posted Prepayment Invoice and will also be printed as text in the document.| |Planned Invoice Date|The agreed date when the prepayment is to be made is entered here. This entry is optional.| |Payment Terms Code|A payment term for the Payment Plan Step that differs from the document can be entered here. This entry is optional.| |Invoice No.|Indicates the Document No. of the invoice used to invoice the Payment Plan Step.| |Invoice Posting Date|Indicates the Posting Date of the invoice used to invoice the Payment Plan Step.| In order for a Payment Plan to take effect, it must be ***Released***. This is done by the action of the same name in the Payment Plan and is displayed in the corresponding field in the *Prepayment* fast tab of the Sales Order. Once a Payment Plan is released, the Payment Plan Steps cannot be changed. To change the steps, a reset is required, which is achieved by the **Reopen** action. After leaving the **Payment Plan Steps** page, the Sales Order (in the *Prepayments* fast tab) will be marked accordingly by the **Payment Plan Exists** field. This field can be used as a filter criterion, for example, to display all Sales Orders with a Payment Plan stored. ### Invoicing a Payment Plan Step Invoicing a Payment Plan Step is similar or almost identical to the procedure for creating Prepayment Invoices (see section [Create Prepayment Invoices](#create-prepayment-invoices) et sqq.). After all information has been entered in Sales Lines and Payment Plan Steps and the Payment Plan has been released, the **Create Prepayment Invoice** action (via *Actions / Payment Plan*) is used to invoke the functionality. The only difference to a *normal* Prepayment Invoice is that the system has already recognized the existing Payment Plan in advance and automatically activated the **Use Payment Plan** indicator. After confirming with OK, the list of possible Payment Plan Steps for this document is displayed. The desired level can be selected with the help of the record marker. An unposted (or if the **Post Invoice** indicator is set, a posted) prepayment invoice will be created for the selected step. :::warning Payment Plan Steps per Prepayment Invoice Only one Payment Plan Step can be selected per Prepayment Invoice at a time. ::: After the Prepayment Invoice is posted, the **Invoice No.** and **Invoice Posting Date** are transferred to the **Payment Plan Steps** page in the previously selected Payment Plan Steps. If another Prepayment Invoice (e.g. for the next step) is created for the same Sales Order, a warning message will appear before posting if there are any unpaid Prepayment Invoices. The user can decide to continue or cancel the operation. If he decides to continue, the next Prepayment Invoice will be created - despite the warning. --- ## Regulate Unit Cost In day-to-day operations, the actual **Unit Cost** on a Purchase Order differs from the default defined in the item master data, leading to inaccurate reporting and margin analysis. To reflect accurate cost information on posted sales documents, **DYCE** brings a functionality to update the **Unit Cost** on posted Sales Invoice Lines once the final purchase cost is known. The update of **Posted Sales Invoice Lines** can be handled automatically by scheduling the **Regulate Unit Cost** report in the **Job Queue**, a standard Business Central feature for automating recurring tasks. For setup instructions, refer to the official [Microsoft documentation](https://learn.microsoft.com/en-us/dynamics365/business-central/admin-job-queues-schedule-tasks). Alternatively, the report can also be run manually by searching for **Regulate Unit Cost** in the *TellMe* search bar (shortcut *Alt+Q*). :::info Job Queue Setup Required Installing the **DYCE IT-Business Toolkit** does not automatically create entries in the Job Queue. Users must manually configure the scheduling of the **Regulate Unit Cost** report, if required. ::: When a Purchase Order is created either by [Create Connected Purchase Orders](/docs/ibt/sales-related-procurement.md) feature or through the [Purchase Requisition](/docs/msp/partial-shipment-and-purchase.md#central-overview-for-purchase-orders) page, **DYCE** ensures that the actual **Unit Cost**, determined at the time of invoicing, is accurately applied to the corresponding **Posted Sales Invoice Lines**. When the **Regulate Unit Cost** report is executed and the **Unit Cost** on the **Posted Sales Invoice Line** is updated, the field **Regulated** is set to *YES*. The **Unit Cost** is calculated by filtering **Value Entries** based on the related **Sales Invoice No.**. The system sums the values in the **Cost Amount (Actual)** field and divides the total by the **Quantity**. If a standard Business Central [cost adjustment](https://learn.microsoft.com/en-us/dynamics365/business-central/design-details-cost-adjustment) is posted in a **Value Entry** for a specific **Sales Invoice No.**, the **Regulated** field on the related **Posted Sales Invoice Line(s)** is automatically reset to *NO*. As a result, the Unit Cost can be updated again using the report or Job Queue. :::note Origin The **Regulated** field is introduced by the [DYCE Essential](/docs/general/essentials/welcome.md) app. ::: --- ## Sales-related Procurement # Procurement in connection with a Sales Order In Business Central, there are several ways to create Purchase Orders for retail items. The most common are the Requisition Worksheets (from the manufacturing module) and the functionality to create Purchase Order from a Sales Order. However, if retail items are needed explicitly for a specific Sales Order, these two options fall short. In both cases, the goods are not ordered on an order-by-order basis. Thus, the reservation of the required quantity in the Sales Order line must be done manually. Especially in the second case, both the order (here: Sales Order line) lacks the link to the Purchase Order (here: Purchase Order line) expected by the user and vice versa. ## Create Purchase Order The functionality to create a Purchase Order (**Create Purchase Orders** in action group *Actions / Functions / Create Purchase Document / Create Purchase Orders*) from a Sales Order has been enhanced with **DYCE IT-Business Toolkit**. The additional action **Create Connected Purchase Orders** can be found directly in the *Home* menu. Calling it up opens the **Create and connect Purchase Orders** page. The page shows the document lines (items) that can be ordered for the current job. It contains the standard fields such as the **No.** of the item, the **Description** and the **Vendor** from which the item should be ordered (for more details regarding the suggested vendor see below in the section [Favorite Vendor](#favorite-vendor)). In addition, the following fields are included: * The **Purchasing Code** indicates whether a special procurement method (e.g., Drop Shipment) is intended for the order line. * The **Demand Quantity** contains the customer demand quantity from the order line. * The **Direct Unit Cost** field contains the purchase price from the order line. This can be changed unless it is part of a special agreement (**[Special Bid](/docs/pb/sales/working-with-sales-docs.md#project-prices-for-purchasing-with-special-bid)**). * In the **Quantity to Purchase** field, the actual quantity to be ordered is proposed. The system considers both the **Demand Quantity** and the current available stock (depending on the location from the Sales Order line) in the proposal. The available stock (depending on the location from the Sales Order line) is displayed in the **Demand Qty. Available** field. * A special agreement (e.g. for project-specific purchase prices) is displayed in the **Special Bid** field (see **Direct Unit Cost**). * The lines to be processed (for which a Purchase Order is to be created) are specified via the **Process** field. With *OK* the processing is triggered, the order is created and opened. :::info Prerequisites for purchasing items In order for an item to be purchased, the following requirements must be met in the Item card: * **Type** = *Inventory* or *Non-Inventory* (fast tab *Item*). * **Replenishment System** = *Purchase* (fast tab *Replenishment*) ::: In the Purchase Order and in the Sales Order, the related other document can be opened. In the Purchase Order, the call **Reserved Sales Orders** (in the line menu under *Purchase Order*) is available for this. In the Sales Order, the function is called **Reserved Purchase Orders** and is also located in the line menu (under *Order*). ## Reservations For inventory items (**Type**=*Inventory*), the expected goods are automatically reserved for the Sales Order line when the Purchase Order is created. This is visible in the **Reserved Quantity** field in both the Sales Order line and the Purchase Order line. Clicking on the field will open the Reservation Entries. Reservations cannot be created for non-inventory items (**Type**=*Non-Inventory*). In this case, the standard functionality of Business Central is triggered and used to create Purchase Orders. ### Favorite Vendor Items can be purchased from different vendors. The respective purchase prices are stored in the (Purchase Prices). With **DYCE IT-Business Toolkit** there is the possibility to mark one of the vendors as the **Favorite**. This is done by calling the **Set Vendor as Favorite** action in the **Purchase Prices** page. This is useful for the vendor that is normally used to purchase this item from. Only one vendor can be set as the favorite. Performing the action will change the **Vendor No.** field in the Item Card if the favorite is different from the vendor selected in the **Vendor No.** field. This favorized vendor will be copied to the Sales document line when it is used in a Sales Line, but it can also be changed there. ### Process 1. **Define favorite vendor** In the master data of the item, a preferred vendor or supplier is stored in the purchase prices. Vendor agreements can, however, be made with all vendors in principle. 2. **Creation of the order** The preferred supplier for the item is automatically entered in the Sales Order line and the related Unit Cost is used. The Unit Costs are maintained in principle by the purchaser and are normally not changed in the Sales Order line. 3. **Negotiation of a special purchase price with a supplier** The negotiated purchase terms apply exclusively to this one Sales Order. The reference number (**Special Bid**) will be placed on the Sales Order line. The Unit Cost will be adjusted depending on the agreement. 4. **Creation of the Purchase Order** The Purchase Order is created directly from the Sales Order. A separate Purchase Order is created for each Special Bid. The reference number will be included in the Purchase Order. When printing or sending (by mail), the reference number is printed on the Purchase Order. Different Sales Order lines with the same supplier and the same reference number can be combined into one Purchase Order. :::info Drop Shipment 1. Changes of the **Unit Cost** in the Purchase line will be transferred to the Sales line, if Drop Shipment is set. 2. In case of Drop Shipment the Purchase Invoice cannot be posted before the Sales Invoices has been posted. This behavior is analogous to the Business Central Standard. ::: :::info Special Order When a Purchase Receipt is posted for a connected Purchase Order created for a Sales Order line with Purchasing Code *Special Order*, any Serial No., Lot No. or Package No. assigned while posting is transferred automatically to the item tracking of the linked Sales Order Line - the same as for Drop Shipment. Assigning the item tracking manually on the sales side afterwards is not necessary. ::: --- ## Setup(Ibt) # Setup of DYCE IT-Business Toolkit **DYCE IT-Business Toolkit** does not necessarily require any special setup. However, setups for the topics [Margin Calculation](/docs/ibt/margin-calculation.md) and the import of [calculations](/docs/ibt/calculation-import.md) are possible. These are explained in the respective sections. ## Data Exchange Definitions for Calculation Import A corresponding *Data Exchange Definition* is required to import data from a file. This is a standard Business Central functionality, which is explained in this part of the Microsoft documentation. As it is fundamental for the import and subsequent further processing of calculations, at least the aspects relevant to the import of calculations are summarized here once again. :::info Example The Data Exchange Definition described here as an example refer to an import file of a calculation that is available as a CSV file in UTF-8 encoding with column separators as semicolons. The Data Exchange Definitions also offer significantly more functionality, such as the export of data. ::: ### Definition for data import To transfer a calculation to the Sales Quote lines, the source file must first be imported. In order for the system to extract the data correctly, it requires a schema that shows exactly how the data is available. This schema is selected by the user at the start of processing. :::tip Note The Data Exchange Definition *DYCE-CI* are supplied as a default with the installation of **DYCE IT-Business Toolkit**. However, this must be adapted to the respective circumstances. For example, the structure of the import files differs per vendor, which is why it is advisable to create separate Data Exchange Definitions. Here, specific specifications such as the number of headers not to be imported, the Vendor No. of the supplier as a [fixed value](/docs/pli/setup.md#fixed-values) or [filter](/docs/pli/setup.md#filters) for footers not to be imported can be set. Data Exchange Definitions can be exported and imported via the respective actions. ::: Data Exchange Definitions can be called up via the menu or the search (*Alt+Q*). The page consists of three parts: * **General** In this part, settings are made that affect the import file itself. The most important fields are: * **File Type** For the import of calculations, *Variable Text* is usually selected here. * **Type** For the import of calculations, *Calculation Import* must be selected here. **File Encoding** The encoding of the Unicode characters for the import file is selected here. **Column Separator** This specifies the separator character used to separate the columns in the import file. This is only relevant for the *Variable Text* file type. **Headers** Here you can set how many header lines the import file contains. This ensures that the header data is not imported. * **Column Definitions** For inexperienced users of Data Exchange Definitions, it may be confusing that this fast tab is displayed *at the bottom* of the page, as this must be filled *before* the related row definitions. The columns to be imported are defined here: * The number of the column in the import file is specified in the **Column No.** field. * The **Name** field specifies the name of the column. For reasons of clarity, it is advisable to use the same name as in the header line of the import file. * The **Data Type** indicates whether the data to be imported is of type *Text*, *Date* or *Decimal*. * The **Data Format** refers primarily to **Data Type**=*Date*. This specifies the formatting of the date in the related field. For a date in German date format, the value *dd.MM.yyyy* must be entered here. * The **Date Formatting Culture** field is used to specify the culture of the date format, if necessary. For example, *de-DE* for the data type *decimal* indicates that the comma is used as a decimal separator in accordance with the German format. * The **Length** field is only relevant if *Fixed Text* is set as the **File Type**. * The other fields are not required for the import described here. **Line Definitions** Only one row needs to be defined in this fast tab so that the mapping between the columns of the import file and the fields of the target table can then be carried out via the **Field Mapping**. Select *Detail* as the **Line Type**, assign a unique **Code** and a **Description** and specify the **Number** of columns to be processed (imported). The automatically created row of the **Line Type**=*Header* is deleted. The following settings must then be made using the **Field Mapping** action: * First, a new assignment must be created using the *PLUS* symbol. * The number *70921368* is entered as the **Table ID**. This is the import table for the calculations. * A descriptive name should be entered in the **Name** field. * The number *70921377* is entered as the **Mapping code unit**. The code unit is used when creating the lines for the calculations. * In the **Column No.** field, a column defined via the *Column Definitions* can be selected and assigned to a target field (in the table defined via **Table ID**) via the **Field ID**. * The other fields are not required for the import described here. ## Sales & Receivables Setup With **DYCE IT-Business Toolkit** there are two enhancements to this setup from the Business Central Standard. ### Calculation Import In addition to the Data Exchange Definition(s) to be used ([see above](#data-exchange-definitions-for-calculation-import)), the **Set default values for Calculation Import** field in the *General* fast tab specifies whether the **Type** field should be automatically predefined when importing calculations. If the preallocation is switched off, no preallocation takes place and the user must define the **Type** of the import line themselves. ### Margin Calculation The **Calculation Base** field in the *Margin Calculation* fast tab defines which method is used to determine the margin. The options *trade margin* or *markup* are available, whereby the Unit Cost is never updated automatically. **Trade Margin** With this standard selection, the calculation is based on the Sales price. **Markup** With this selection, a surcharge is calculated on the Unit Cost. There is also the possibility of specifying an optional **Rounding Precision** and defining the **Rounding Method**. The **Rounding Precision** affects the **Profit Margin (LCY)** in the Sales line, the **Rounding Method** determines the direction in which rounding takes place. With the standard selection *Nearest*, rounding takes place to the nearest suitable decimal number, with rounding up from *5*. Examples of the different calculation bases can be found in the related [section](/docs/ibt/margin-calculation.md#different-calculation-bases). ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCEIBTALL (DYCE IT-Business Toolkit Read)** This permission set can be assigned to all users. It includes read-only permissions to use the components of **DYCE IT-Business Toolkit**. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCEIBTUSER (DYCE IT-Business Toolkit Edit)** This permission set is for all users working with [Payment Plan](/docs//ibt/payment-plan.md) and the [import of Vendor Configurations](/docs//ibt/calculation-import.md). The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCEIBTADMIN (DYCE IT-Business Toolkit Admin)** This permission set is designed for Administrators and Power Users who should additionally be able to make adjustments to setup of Margin Calculation and the import of Vendor Configurations. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information on permission sets, see this part of the Microsoft documentation. --- ## After-Sales Subscriptions # Subsequent sale of Subscriptions The feature described in this section simplifies the addition of Subscription Lines to existing Subscriptions, aligning with existing workflows in **DYCE Managed Service Providers**. In order to sell and add additional subscription lines to an existing Subscription, set the **Type** field in a Sales Quote or Sales Order line to **[Subscription](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/working-with-contracts/service-objects)**. Afterwards, the lookup in **No.** shows a filtered list of Subscriptions based on the **Sell-to Customer No.** from the Sales document. After selecting a **Subscription**, the remaining fields are filled in a standard way, with slight adjustments to the following fields: * **Quantity**: Transferred from the selected Subscription and is not *editable*. * **Unit Price excl. VAT**: The determination of the Unit Price for Sales lines with **Type**=*Subscription* is based on either the Sales Price List or the Item Card of the Subscription's item (no changes to price calculation itself). ## Add Subscription Lines When the **Add Service** action is called for a line with **Type**=*Subscription*, the page **Assign Subscription Lines** opens up automatically. The system shows all Subscription Packages for the Subscription's item that have not yet been applied. It is possible to remove the filter and additionally show all the packages that have already been used. When the wizard is finished and executed, **Sales Subscription Lines** are created for the selected Subscription. The process for creating Sales Subscription Lines is the same as explained [here](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/sales/sales-service-commitments). Upon shipping a Sales Order with a *Subscription* line, the Sales Subscription Lines associated with that Subscription are automatically converted into **[Subscription Lines](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/working-with-contracts/so-service-commitments)** for the existing Subscription. The Subscription is hereby updated. :::info Important for auditors In Sales Quotes and Orders, the behavior of a *Subscription* line differs significantly from that of *normal* items from the Business Central Standard, aligning instead with the behavior of Subscription Items. The differences is also noted and explained [here](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/sales/sales-service-commitments#shipping-subscription-lines). ::: --- ## Fixed Subscription term # Fixed Subscription Term In software retail business, it is common to purchase a license from the manufacturer as a full version (initial sale). Subsequent renewals and extensions (e.g. for updates) are sold afterwards. Such contracts usually have a fixed term, e.g. one year, and are not automatically renewed. The retailer or customer is responsible for monitoring this, not the software manufacturer. However, the renewal must be initiated. The **Fixed Subscription Term** is used to map such contractually defined terms. The **Subscription Option** field on the Item Card (in the *Prices and Sales* fast tab) provides, among others, the option **Fixed Subscription Term**. An item marked liked this requires a start and end date of the Subscription Line to be specified when used or processed. :::info Monitoring expiring Subscription Lines Subscription Lines with a fixed term are valid for a certain period. They end automatically at the agreed date. ::: ## Subscription Lines with a fixed term The Subscription Package used for a *fixed term* are set up in the same way as *normal* [Subscription Packages](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/masterdata/service-commitments). However, the **Fixed Subscription Term** indicator must also be set in the Subscription Package. :::note Subscription Package for fixed terms Only one Subscription Package can be defined for use for fixed terms. ::: ## Use of items with Fixed Subscription Term If an item with **Fixed Subscription Term** indicator set is used in a Sales line, the Subscription Package with the **Fixed Subscription Term** indicator is automatically applied. The item cannot be shipped unless the **Term Start Date** and **Term End Date** fields have been filled in the Sales line. The dates are then interpreted as **Subscription Line Start Date** and **Subscription Line End Date** when the Subscription Lines are generated. As these are usually retail items, Purchase Orders can be used to procure them from the supplier or manufacturer. Before the Purchase Order is posted (items receipt), the system requires the **Term Start Date** and **Term End Date** to be specified (in the Purchase Order line). With the posting of the shipment, the dates is transferred to the related Sales line. :::note Subscription Once the Sales Order with a **Fixed Subscription Term** item is shipped, a new Subscription is created. ::: :::info Warehouse Shipments and Drop Shipments This procedure is compatible with both Warehouse Shipments and simple, order-related Purchase Orders. In addition, Drop Shipments (Business Central Standard - without Warehouse Shipments and **[DYCE](/docs/msp/partial-shipment-and-purchase.md#drop-shipment)** - with Warehouse Shipments) are also supported. ::: --- ## Purchase and Sales # Partial shipments with Warehouse Shipments based on a Sales Order Partial shipments from Sales Orders are mapped using Warehouse Shipments. In order for a Warehouse Shipment to be created, a Location with **Require Shipment**=*YES* must be used. The **Create Warehouse Shipment (interactive)** action opens a page for selecting items and their quantity, with which the Warehouse Shipment will be created. Sales lines with a Location with **Require Shipment**=*NO* are not displayed in the selection page. The **Shipment address** can be adjusted in the page header and you can specify whether the Warehouse Shipment should be opened after creation. In the lines, the **Quantity to be transferred** field is used to specify the quantity to be transferred to the Warehouse Shipment line. The entry is confirmed with *OK* and the Warehouse Shipment is created. If no quantity is entered, the item will not be transferred to the Warehouse Shipment. :::info "Create Warehouse Shipment" action moved The Business Central standard action **Create Warehouse Shipment** is moved to *More Options* when **DYCE Managed Service Providers** is installed in order to avoid confusion. ::: :::warning Caution when using Order Planning The use of **Order Planning** is not recommended when using **DYCE Managed Service Providers**. It can still be used to create Purchase Orders from Warehouse Shipments. Under certain conditions, however, incorrect data can be created. ::: ## Automatic reservation of stock levels Quantity in stock can be reserved automatically when a Warehouse Shipment is created. The quantity to be used in the Warehouse Shipment can be adjusted before creation. Accordingly, only what is to be shipped to the customer is reserved. If the quantity in stock does not cover the requirements of the Warehouse Shipment, the quantity available is reserved and the remaining quantity can be purchased from the supplier. If the item *requires* a serial number, the reservation is made without a serial number. However, the serial number *must* be entered before the Warehouse Shipment is shipped. This allows items to be reserved without knowing the serial number. The warehouse employee can add the serial number before shipping. The automatic reservation has two limitations: 1. Manual reservations are not possible With **Require Shipment**=*YES* in the Location, reservations cannot be created manually in the Sales Order or Purchase Order lines. 2. Items with **Reserve**=*Always* cannot be used In Sales lines with items that use **Reserve**=*Always*, no Location with **Require Shipment**=*YES* can be entered (Sales Order or Purchase Orders). It is still possible to delete reservations. For **Drop Shipment (Whse.)** - analogous to the Business Central Standard - no reservations are created against stock. :::tip To open a **Warehouse Shipment**, the user must be set up as a **Warehouse Employee** for the corresponding location. Otherwise, Warehouse Shipments are not visible to the user. ::: ## Central overview for Purchase Orders The **Purchase Requisition** page displays all Warehouse Shipment lines, for which Purchase Orders have to be created. Warehouse Shipment lines are grouped by Sales Order and sorted by Item No. New Purchase Orders are to be created if the quantity has not yet been fully transferred to a Purchase Order or reserved against stock. The quantity to be purchased is displayed in the **Quantity to Purchase** field. It is calculated from the quantity in the Warehouse Shipment line minus the reserved quantity (in stock or in Purchase Orders) and already shipped quantity in the Warehouse Shipment line. The **Drop Shipment (Whse.)**, **Unit Cost** and **Vendor** fields can be changed on the page. A change to **Drop Shipment (Whse.)** only affects the Warehouse Shipment line, but not the Sales line. The **Unit Cost** can be edited freely, but is also not transferred back to the Sales line. Any **Vendor** for which there is a Purchase Price List line can be chosen. If there is no line in a Purchase Price List, the action **[Assign Vendor](#assign-vendor)** can be used to create that line. ### Create Purchase Orders The **Create new Purchase Order** action creates Purchase Orders for all *selected* lines. A reservation is created for the Warehouse Shipment lines that are transferred to a Purchase Order. The reservation maintains the link between the Purchase Order and the Sales Order. Warehouse Shipment lines with different Vendors, Drop Shipment (Whse.), different Special Bids etc. cannot be included in the same Purchase Order. The following criteria determine which Warehouse Shipment lines are created together as lines in a Purchase Order and for which Warehouse Shipment lines a new Purchase Order is created: 1. If the **Vendor** differs, separate Purchase Orders are created. 2. If **Special Bid** is different, separate Purchase Orders are created. 3. If the **Purchase Codes** are different, separate Purchase Orders are created. 4. If the Warehouse Shipment line is marked as **Drop Shipment (Whse.)** and the **Ship to Customer** in Warehouse Shipment differs between Purchase Order and Warehouse Shipment, separate Purchase Orders are created. 5. If the Warehouse Shipment line is marked as **Drop Shipment (Whse.)** and the **Shipping Address** in the Warehouse Shipment differs between the Purchase Order and the Warehouse Shipment, separate Purchase Orders are created. 6. If the Warehouse Shipment line is marked as **Drop Shipment (Whse.)** and the **Sell to Customer** in Warehouse Shipment differs between the Purchase Order and Warehouse Shipment, separate Purchase Orders are created. 7. If the Sales line for the Warehouse Shipment line is marked as **Special Order** and the **Sell to Customer** in the Warehouse Shipment differs between the Purchase Order and the Warehouse Shipment, separate Purchase Orders are created. 8. If the Warehouse Shipment lines are marked as **Drop Shipment (Whse.)** and were created from the same Sales line, a new Purchase Order is created. 9. If the Sales line / Warehouse Shipment line is marked neither as **Drop Shipment (Whse.)** nor as **Special Order** and the **Sell to Customer** is empty in the Purchase Order, a new Purchase Order is created. :::note Extended Criteria When the **[Licensee](/docs/ibt/licensee.md)** feature from **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** is used, the existing criteria (*see above*) is extended with an additional condition: * If **Customer Name**, **Contact Name**, or **Email** (from Sales Line) differ between Purchase Order and Sales line, a new Purchase Order is created. ::: Only Purchase Orders that are created by **Create new Purchase Order** action are taken into account, Purchase Orders that were created before are not. Once all Purchase Orders have been created, a list of the created Purchase Orders is opened. ### Extend Purchase Order The **Extend Purchase Order** action can be used to add a Warehouse Shipment line to an existing Purchase Order. If the Purchase Order has already been *released* or the criteria for creating purchase orders ([see above](#create-purchase-orders)) do not apply, no line is created in the Purchase Order. ### Assign Vendor If there is no Purchase Price List line for a Vendor and the item in the Warehouse Shipment line, the Vendor cannot be selected. A line in a Purchase Price List can be created with the **Assign Vendor** action. If there is already a line in a Purchase Price List for the item and Vendor, the Vendor is entered. If there is no such line, a line in a Purchase Price List is created with the Unit Cost from the Warehouse Shipment line. ### Drop Shipment Drop Shipments cannot be used in combination with Warehouse Shipment in Business Central Standard. In order to still be able to work with Drop Shipments, the new field **Drop Shipment (Whse.)** has been created. The field can be set in the **Purchase Code**, Sales lines and also in the **Purchase Requisition** page. If an item with a Purchase Code with **Drop Shipment (Whse.)**=*YES* is used in a Sales line, the field of the same name in the Sales line is set to *YES*. The value is transferred from the Sales line to the Warehouse Shipment line (**[Create Warehouse Shipment (interactive)](/docs/msp/partial-shipment-and-purchase.md)**). If **Drop Shipment (Whse.)** is changed in the **Purchase Requisition**, the change is transferred to the Warehouse Shipment line, but not to the Sales line. At the same time, changes in the Sales line are not transferred to existing Warehouse Shipment lines. **Drop Shipment (Whse.)** may not be changed, if a Purchase Order has already been created, if there are Reservation Entries or if the Warehouse Shipment line has already been (partially) shipped. In the Purchase Order lines, the **Quantity** and **Qty. to Receive** fields may not be changed if it is a **Drop Shipment (Whse.)**. When the Purchase Order is posted (received), the Warehouse Shipment lines are shipped automatically. ## Purchase Order Warehouse Shipment lines, for which Purchase Orders have been created, are no longer displayed on the **Purchase Requisitions** page. Purchase Order lines can be deleted, quantities changed, Reservation Entries adjusted, new lines added, etc. If an Purchase Order line is deleted, the Reservation Entry is deleted at the same time and the Warehouse Shipment line is displayed again in the **Purchase Requisition** page. The same applies if the quantity in the Purchase Order line is reduced. The quantity in the Reservation Entry is reduced accordingly and the remaining quantity is displayed as *Quantity to Purchase* in the **Purchase Requisition** page. If, on the other hand, the quantity in the Purchase Order line is increased, there is no change in the Reservation Entry, the Purchase Requisition or the Warehouse Shipment line. The additional quantity is ordered to stock. Drop Shipments are an exception, as they are sent directly to the customer ([see above](#drop-shipment)). ### Receiving goods After the goods have been received and accepted from the supplier, they need to be sent to the respective customer as quickly as possible. With the **Commissioning Document**, the items can be quickly assigned to the customers and forwarded. The document can be printed in **Warehouse Shipment** if required. In order to print it automatically when posting a Purchase Order (*Receiving* and *Receiving and invoicing*), **Print Commissioning Document** must be set to *YES* in **Purchases & Payables Setup**. If **Print Commissioning Document** is set to *YES*, a request page is opened when the Purchase Order is posted. If confirmed, the picking documents are printed for all Warehouse Shipments for which goods were received with this delivery (Purchase Order). :::warning Note Commissioning documents can only be printed, if exactly one Purchase Order is selected and posted. If several Purchase Orders are posted, no request page appears and the commissioning documents will not be printed automatically. ::: When the Purchase Order is posted, the quantity received is set as **Qty. to Ship** in the relevant Warehouse Shipment lines. :::info Dealing with errors when posting warehouse shipment The **Shipment Posting Policy** field on the **Warehouse Setup** page defines how errors are handled when posting Warehouse Shipment: * **Stop and show the first posting error** displays errors as soon as they occur and cancels the posting. * **Posting errors are not processed** does not display the error and cancels the posting for affected Warehouse Shipment. ::: --- ## Setup(Msp) # Setup of DYCE Managed Service Providers **DYCE Managed Service Providers** requires some settings, which are described below. ## Location To use Warehouse Shipment with partial shipments, a **Location** with **Require Shipment**=*YES* must be used. Sales lines with a Location, that specifies Warehouse Shipment as required, can only be shipped via Warehouse Shipment lines. In addition, the default location for non-inventory items can be set up in the **Non-Inventory Location** field on the **Warehouse Setup** page. This overwrites the value from the customer for non-inventory items in Sales Quotes and Orders. ## Purchasing Codes To be able to use Drop Shipments in Warehouse Shipments, the **Drop Shipment**=*NO* and **Drop Shipment (Whse.)**=*YES* indicators must be set. Both fields can be edited in the Purchasing Codes (and the Sales lines). ## Require Shipment Partial shipments from Sales Orders are mapped using Warehouse Shipments. For a Warehouse Shipment to be created, a Location Code with **Require Shipment**=*YES* must be used. ## Permissions In principle, no additional permission sets are required. Further information on permission sets can be found in this part of the Microsoft documentation. --- ## Subscription Renewal page # Subscription Renewal In service-driven industries, long-term customer satisfaction relies, among others, on the ability to monitor and extend service agreements beyond the initial sale. With **DYCE Managed Service Providers**, users often create subscriptions such as **Warranty Extensions** or with **Fixed Subscription Terms**, each with defined validity periods. Over time, the need arises to track these service agreements centrally, especially as they approach expiration. Without a dedicated overview, users risk missing renewal opportunities, leading to lost revenue or reduced customer satisfaction. To support this, a dedicated page is provided where all relevant subscriptions are listed with key validity details. This overview enables users to directly initiate actions to offer renewals, ensuring a streamlined renewal process and improved customer retention. ## How Subscription Renewals work The **Subscription Renewal** page provides a dedicated list view based on the Subscription Line table, displaying all relevant information needed to track expiring lines and perform follow-up actions like renewals. It enables users to filter, select, and extend subscription lines directly, supporting proactive [after-sales](/docs/msp/after-sales) service activities. To enhance this process, **[DYCE Cockpit](/docs/cp)** provides enhancements to the dashboards or role centers. This addon allows users to monitor the validity of subscription lines marked as [Warranty Extension](/docs/msp/warranty-extension) or [Fixed Subscription Term](/docs/msp/fixed-subscription-term). Users can easily filter these lines based on key fields (e.g. Subscription Line End Date, Warranty Extension, or Fixed Subscription Term) directly or even us it as a cue in **[DYCE Cockpit](/docs/cp/cockpit.md)**. The page thus provides a centralized view of expiring [Warranty Extension](/docs/msp/warranty-extension) and [Fixed Subscription Term](/docs/msp/fixed-subscription-term), helping users to track expiring subscriptions and initiate appropriate follow-up actions. The **Subscription Renewal** page displays a list of subscription lines that help users filter, and manage renewals efficiently. The following fields available on the page: * **Process** indicates the current stage of the sales process for the subscription line. It can be *empty* if no follow-up action has been taken. If a Sales Quote has been generated, the status will be set to *Sales Quote created*. Once that quote is converted into a Sales Order, the status updates to *Sales Quote processed*. If the subscription is not extended, the status becomes *Canceled / not extended*. * **Subscription No.** specifies the unique number of the subscription, while **Subscription Description** and **Subscription Line Description** provide information on subscription and subscription line. * **Subscription Line Start Date** and **End Date** define the validity period of the subscription line. * The **Next Billing Date** field shows the next possible billing date. * **Quantity** and **Amount** reflect the subscription quantity and the total amount (including discount) of the subscription line. * **Partner Name** refers to the End-User partner who receives the service and is invoiced. * **Item for Warranty Extension** defines which item will be used to generate an additional subscription line for warranty extension purposes. This field is typically empty by default and cannot be selected for *Fixed Subscription Term*. * **Sales Quote No.** shows the number of the related Sales Quote created as part of the renewal process. Additionally, the fields **Item No.**, **Billing Rhythm**, **Price**, and **Discount %** are available on the page but are hidden by default. On the **Subscription Renewal** page, two main actions are available to support the renewal process of expiring subscription lines: * When **Create Sales Quote** is selected, a dialog prompts the user to choose whether to create a new Sales Quote or attach the subscription line to an existing one. Existing Sales Quotes are filtered by the **End-User** defined on the subscription. * The **Cancel** action sets the **Process** field to *Canceled / not extended*, indicating that the subscription line will not be extended. This action can only be executed if no Sales Quote has been created or processed for the selected subscription line, that is if the **Process** field is *not* set to either *Sales Quote created* or *Sales Quote processed*. :::note These actions can only be executed for multiple records if all selected subscription lines are marked as **Fixed Subscription Term**. Mixed selections or lines marked as **Warranty Extension** are not supported and the action will therefore be disabled. ::: ### Renewal - Warranty Extension When the **Create Sales Quote** action is triggered for lines marked as **Warranty Extension**, the system will either create a new Sales Quote or attach lines to an existing one, depending on the option selected in the dialog. In both cases, the **Type** and **No.** fields on the Sales Quote line will be set to *Subscription* and the corresponding *Subscription No.* from the selected line on the **Subscription Renewal** page. The *Customer* on the Sales Quote is determined based on the **End-User** defined in the subscription. When attaching a line to an existing Sales Quote, only quotes for the same end-user are available for selection. When the **Item for Warranty Extension** field is set on the **Subscription Renewal** line, two lines are added to the Sales Quote: * First line for the *Subscription* - with **Type** set to *Subscription* and **No.** set to the corresponding *Subscription No.* * Second line refers to the **Warranty Extension item** specified on the **Subscription Renewal** page, with **Type** set to *Item* and **No.** selected from the **Item for Warranty Extension** field. After both lines are added, the **[Warranty Extension Wizard](/docs/msp/warranty-extension#warranty-extension-wizard)** is triggered automatically. The **Process** field on the **Subscription Renewal** line is then updated to *Sales Quote created*. When the Sales Quote is converted to a Sales Order, the **Process** field is further updated to *Sales Quote processed*. Once the Sales Order is posted or shipped, a new subscription line is created to extend the current subscription. The use of the **Warranty Extension Wizard** and its related process is described [here](/docs/msp/warranty-extension) in more detail. :::info If the **Item for Warranty Extension** is not selected on the **Subscription Renewal** page, only one line is added to the Sales Quote. ::: ### Renewal - Fixed Subscription Term When the **Create Sales Quote** action is triggered for one or more lines marked as **Fixed Subscription Term**, the system either creates a new Sales Quote or adds the lines to an existing one, depending on the option selected in the dialog. In both cases, the **Type** field on the Sales Quote line is set to **Item**, and the **No.** field is populated with the *Item No.* from the related **Subscription** selected on the **Subscription Renewal** page. The system checks the **Subscription** header and uses the **End-User** information either as the **Customer** for the Sales Quote or to filter existing quotes. The **Item No.** defined in the subscription is used to populate the Sales Quote line. Once the Sales Order is posted or shipped, a new **Subscription** with the corresponding lines will be created. The use of **Fixed Subscription Term** and its related process is described [here](/docs/msp/fixed-subscription-term) in more detail. --- ## Warranty Extension In sales scenarios, it is common to offer additional services, such as extended warranties, which are offered and sold separately but are linked to the original sale. These warranty extensions are managed either by the reseller, who is responsible for monitoring and initiating the renewal, or by the customer themselves. Warranty extensions represent this use case in **DYCE Managed Service Providers**. The **Subscription Option** field on the Item Card (in the *Prices and Sales* fast tab) provides, among others, the option *Warranty Extension*. ## Setting Up Subscription Packages The Subscription Packages used for *warranty extension* purposes are set up in the same way as *normal* [Subscription Packages](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/masterdata/service-commitments). However, the **Warranty Extension** indicator must be set in the Subscription Package. :::info Multiple Warranty Extension Packages You can mark as many Subscription Packages as you want as **Warranty Extension**. ::: ## Use of Warranty Extension items When selling additional services such as warranty extensions, the system provides a guided wizard to help link these supplementary items to an existing subscription lines, i.e., a sales line in this case. This process ensures correct assignment and creation of related Sales Subscription Lines. If an item with **Warranty Extension** indicator set is used in a sales line, the [Warranty Extension Wizard](#warranty-extension-wizard) opens automatically if it is a sales order. For Sales Quotes, it can be triggered manually (in action group *Functions* in the Lines menu), though. When starting the wizard, the system checks whether there are other document lines with items for which the **Subscription Option** is not set to *Warranty Extension*. If no such line exists, the wizard will not open automatically. In this case, a manual call leads to an error, as the system cannot use a line for the warranty extension. If at least one applicable sales line is found, the [wizard](#warranty-extension-wizard) opens up and displays the Subscription Packages marked as *Standard* in the **Subscription** tab. When the wizard is completed, additional **Sales Subscription Lines** are created for the main item selected in the **Assigned** section of the wizard. The **Quantity** on the supplementary line (the item marked as *Warranty Extension*) is automatically aligned with the *target* sales line. When the main item is shipped, a **Subscription** is created following the process described [here](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/sales/sales-service-commitments). For the supplementary item with **Subscription Option** set to *Warranty Extension*, no **Subscription** or **Subscription Lines** are created during posting, as they have already been assigned to the main item. The supplementary item is posted following the standard procedure. :::note Sales Subscription Lines The creation of these additional Subscription Lines follows the standard process described [here](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/sales/price-calculation), using the information provided through the [Warranty Extension Wizard](#warranty-extension-wizard). ::: :::info Deleting the Supplementary Item If the supplementary item with **Subscription Option**=*Warranty Extension* is deleted, the related **Sales Subscription Lines** are automatically deleted, as well. ::: ## Warranty Extension Wizard The wizard consists of three tabs: *Assignment*, *Parameters*, and *Subscriptions*. ### Assignment * The **Line No.** field is filled automatically: the system first looks for a sales line with a **Line No.** lower than the one containing the *Warranty Extension* item, selecting the first valid match by searching bottom to top; if no such line is found, it continues searching lines with a higher **Line No.** using the same criteria. * In the **Assignment** section, the fields **Item No.** and **Description** are automatically filled based on the selected *main line*. * In the **Item for Warranty Extension** section, the fields **Item No.** and **Description** display the values from the sales line marked as *Warranty Extension*. :::info Main Line The main item must have a valid **Subscription Option**, such as *Sales with Subscription* or *Subscription Item*. Alternatively, a **Subscription** can be selected instead of an item. ::: ### Parameters * The field **Default Subscription Start Date**, if filled, sets the **Agreed Subscription Line Start Date** on the **Subscriptions** tab. This value is transferred when the **Sales Subscription Lines** are created. * The field **Default Service Start Formula**, if filled, is applied as the **Subscription Line Start Formula** on the **Subscriptions** tab and is transferred during the creation of **Sales Subscription Lines**. :::warning Caution Only one of the two fields can be used: either a *date* or a *formula*, not both. ::: ### Subscription Lines The lines of the **Subscription Packages** of the warranty extension item that are marked as *Standard* are displayed here. Slight adjustments may apply depending on the values entered in the **Parameters** tab. Subscription Line values are calculated using the **Warranty Extension line** as the source for **Price**, and the *target* sales line as the source for **Quantity**, for which the additional **Sales Subscription Lines** will be created. Each time the *target* sales line is changed, the Subscription Line values are automatically recalculated based on the newly selected line. The **Add Subscriptions** action is available in the wizard under the **Subscriptions** tab. When triggered, it displays only **Item Subscription Packages** where the **Warranty Extension** indicator is set and **Standard** is set to *NO*. Once a package is selected, its lines are shown in the **Subscriptions** tab, and the process continues as previously described. --- ## Setup(Swt) # Setup of DYCE Smart Workflow Tool To process a document (such as a Sales order or a Purchase order), many individual process steps are often necessary, which take place one after the other and may also require the use of different users. The **DYCE Smart Workflow Tool** provides process control functionality for specifying these steps and documenting their completion or for transferring a document to another user. This process control essentially consists of a workflow or process, which is selected for each document or operation, the associated process steps, which are mapped via so-called process statuses, and possibly via additional functionalities that are assigned to the individual process status. ## Definition of a process Processes are set up via the **Processes** page, which is available in various places. After assigning a unique **Code** and a **Description**, the scope to which the process is to be applied is defined. This is done by selecting the table in the **Table name** field and, if necessary, further filters, which can be defined depending on the context either via the **Filter exists** field or via the **Edit filter** action. To simplify the creation of a new process, **Process Templates** can be defined in which the scope (table and filter, if applicable) can already be predefined. When creating a new process, a suitable template can be selected using the **New from Template** action. In addition, an existing process including the associated [process status](#definition-of-associated-process-statuses) can be duplicated using the **Copy Process** action and then adapted. :::tip Multiple processes for the same document type It can be useful to define several processes for the same document type (e.g. Sales quotes) if they differ in their process steps. In sales, for example, the standard processing of quotes and orders typically differs from those that are combined with a project. The process code therefore also serves as a characteristic of the document type, which can be used to differentiate and filter. ::: ## Definition of associated process statuses All steps that may be required for a process are defined in the **Process Status** page, which can be called up on the **Processes** page via the **Status** action. The sequence of defined process statuses then forms a workflow. The **No. of actions** field or the **Status Actions** action can be used to define so-called *status actions* for each status, which are then executed when the status is set. Several actions can be defined on the page of the same name. Reports, codeunits and Business Events are initially available for selection via the **Type** field, which are specified using the **ID**. ## Definition of the pool of all statuses All required process statuses are defined system-wide in the **Status** page, which forms the pool of all process statuses. A status defined here can be used for different processes. :::note Prefix in status It is advisable to define the status codes that describe the typical process flow with a prefix that identifies the document type and a consecutive number. ::: ## Business events and external systems {#business-events-and-external-systems} There are 20 generic business events to choose from. Business events provide a mechanism for triggering actions in external systems from Business Central. A business event only indirectly causes actions in other systems. When the status is set, the business event is sent to all Listeners, who have subscribed to it. All systems that have permission and *listen* to this business event can observe it and are triggered, when they perceive the business event. For example, if status *SO 001* triggers the business event *1 DYCE SWT 01* and status *SO 002* triggers the business event *2 DYCE SWT 02*, all external systems that listen for *2 DYCE SWT 02* are triggered when status *SO 002* is set. ### Power Automate Power Automate is perfect for triggering follow-up actions after a status has been set. The possibilities are almost unlimited, which is why the documentation only covers the initial setup. Create a new flow and use the trigger **When a Business Event occurs (V3)**. Make sure you are connected to the correct Business Central environment. After selecting the environment, the **Business Event** that is to trigger the flow can be entered as an event. Once the flow has been activated, it is triggered as soon as the business event is set by a status in the environment. The flow can be restricted to companies and Document Types, using further steps such as **Get Record (V3)**. In this way, the business events in different clients and documents can trigger different flows. ## Permissions {#permissions} This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCESWTALL (DYCE Smart Workflow Tool Read)** This permission set can be assigned to all users. It only contains read permission for processes and statuses. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCESWTUSER (DYCE Smart Workflow Tool Edit)** This permission set should be assigned to all users who should be able to set process statuses. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCESWTADMIN (DYCE Smart Workflow Tool Admin)** This permission set is designed for administrators and power users who should also be able to design processes and reset statuses set by other users. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. Further information on authorization sets can be found in this part of the Microsoft documentation. --- ## Smart Workflow Tool # Use of a process in a document Processes and process statuses allow users to categorize and filter documents. ## Selection of the process To apply a process to a document, it is necessary to assign a process to the document. This selection is made via the **Process** field in the *General* fast tab. It shows all processes that are possible for the document (see [here](/docs/swt/setup.md#definition-of-a-process)). When processing a Sales order, for example, it is possible to choose between different processes, each of which requires a different process procedure with different process steps and different functionalities. One of the most common distinctions for Sales orders is between standard orders (e.g. simple sale of goods) and extensive project orders that include services in addition to goods. ## Setting a process status Every user who wants to set a status in the document after defining the process can choose from the process statuses that have been defined for the process (see [here](/docs/swt/setup.md#definition-of-associated-process-statuses)). Typical cases in which setting a process status can be useful are * initiating a new process step, often indirectly linked to forwarding processing to another user (e.g. *Quote to be checked*, *Order awaiting invoice*, *Transfer requirement to development*), * mark a process step as completed (e.g. *Quotation checked* or *Invoice sent*), * the description of a wait status (e.g. *Waiting for customer info*) or * initiating a functionality, such as the automatic release of the document. Setting a process status is triggered with the action **Set Process Status** (*Alt+S*) in the document and the page with the list of process statuses associated with the process is called up. A status is selected from this list and then set with **OK**. The user is supported in selecting the process status by the next possible process status (after the current status already set) being automatically suggested. However, it is possible to deviate from the preselection and select any other status. This means that process statuses that have already been set can also be used again (see [here](#repeat-loop-in-the-process)). Not all available process statuses have to be set - process statuses can be skipped. The **Status History** page shows the statuses that have already been set. The last status set can also be deleted here if the user has set it themselves. :::info Reset status A set process status can only be reset by the user who originally set the status or by an admin (assuming appropriate [access rights](/docs/swt/setup.md#permissions)). ::: ## History of process statuses The last status set in the document is displayed in the **Process Status** field. Using its lookup, you can access a process status table (depending on the selected **process**) in which both a new status can be set (upper part of the page) and all statuses set up to that point (lower part of the page, **Status History**) can be viewed. In addition to the information on the process status itself, this page shows when and by whom which status was set. This history is created automatically, including date stamp and user ID. A set status can only be removed by the user themselves or by an administrator (see info *Reset status*). The **Delete last status** action is used to reset the status. In the **Process Status** page, additional statuses can also be added via lookup in the **Status Description** field to select an additional process status that is not in the list. This can be set with **OK** and the page closed. ## Repeat loop in the process A repeat loop in the process is achieved by the user setting a process status that has a previous value in the list. The next time a status is set, its successor is offered again, i.e. the process is run through again from this status onwards. :::info Example of a repeat loop The starting point is a process for a Sales quote. * An employee in Sales creates a quote and sets the status SQ0-000 - *Quote created*. * He then initiates a technical check of the content of the Sales quote (SQ1-030 - *Quote to be checked*). * This check is carried out by the specialist department, which comes to the conclusion that the information required for the check is missing. * The specialist department therefore sets the Sales quote to process status SQ1-010 - *Quote unclear*. The quotation process is now run through again, in which the employee revises the quote and then sets the status SQ1-030 - *Quote to be checked*. * If the technical check had been positive, SQ2-040 - *Quote checked* would have been set and the internal sales department could then send the quote. ::: ## Execute an action when setting a process status Actions can be executed when a status is set. To do this, one or more actions are assigned to a status on the **Status Actions** page, whereby an action can be implemented as a report or codeunit. Only one report (*70921246 - SA Release Document*) is currently available for releasing the current document. If required, further objects for status actions can be added - either in the scope of delivery of **DYCE Smart Workflow Tool** or as a customer extension. There are two additional fields in the background that are not displayed by default, but can be displayed if required: * **Show Request Page** This indicator controls whether the *report object* is executed with its default settings or with its query (in which parameters are typically also queried). In the latter case, this field must be checked. The indicator only applies to objects of the type *Report*. **Commit after execution** This indicator controls whether a COMMIT command is executed after the object has been processed. :::note Technical note In principle, any report and codeunit whose primary DataItem matches the data record for which the status is to be set (e.g. Sales header) can be executed as an action. ::: --- ## Import Price List In the **Import Price List** page, price lists can be imported and processed. All imported lines are displayed and can be edited before further processing. The purchase and unit prices in Catalog items and items are updated with the **Process Price List** action. ## Import Importing a price list can be done only if no lines exist in the **Import Price List** page. Process and delete existing lines before importing new ones. The **Import** action in the menu opens a page for selecting the [Data Exchange Definitions](/docs/pli/setup.md) and the import file. Confirming the selection imports the selected price list with the filters and fixed values and displays all imported lines. ## Process price list The **Process Price List** action processes all displayed lines and creates Catalog Items. After a line has been successfully processed, the **Catalog Item Created** field is set to *YES*, the date and time are entered in **Processed on**, and the executing user is documented in **Processed by**. If **Delete lines after processing** is checked, all successfully processed lines are automatically deleted. In **Price List Valid From** the date from which the purchase prices are valid can be entered. The date from **Price List Valid From** will be used in all lines where **Valid From** is not filled. ### Creating and updating catalog items In the Catalog Item, there is information about the suppliers, cost costs, minimum quantities, etc. in the lines and the **Manufacturer Code** and **Manufacturer Item No.** fields in the header. If a Catalog Item with the same **Manufacturer Code** and **Manufacturer Item No.** is found when processing a line, it will be updated. Otherwise, a new Catalog Item will be created. If a line already exists for the catalog item with the same combination of **Vendor No.**, **Vendor Item No.**, **Minimum Quantity**, **Currency Code** and **Unit**, it will be closed as of the validity date of the new line. A **Valid To** date is entered in the existing line, and a new line is created with the values from the current import. By comparing the old and new lines, price developments can be tracked. ### Creating and updating items When an item is created from a Catalog Item, the lines from the Catalog Item are copied to the standard purchase prices of the item. At the next import, when the Catalog Item is updated, the purchase prices on the related item are also updated. The unit price is updated in the Item card during processing. :::tip Creating Catalog Items as batch processing The **Create Item** action creates items for all selected Catalog Items. In the list, it is possible to create several items at once by selecting several Catalog Items before calling up the action. Only one item is created when the action is called up from the Catalog Item card. ::: ## Supplier reference for usage data If **[Microsoft Subscription Billing](https://learn.microsoft.com/en-us/dynamics365/business-central/ubb/welcome)** (usage-based billing) is used, it is possible to import *supplier references* that are required for the subsequent processing of usage data. In the IT industry this is especially interesting for importing price lists of Microsoft CSP/NCE items or from other vendors. Both price lists from Microsoft (for *Microsoft Tier 1 partners*) and from distributors (for *Microsoft Tier 2 partners*) can be processed. The unique supplier reference, which is important for the subsequent processing of usage data, is either imported as a whole or assembled from several parts. ### Data Exchange Definitions If the value *Import Price List* is selected for a Data Exchange Definition in the **Type** field, the **Create Supplier Reference** and **Supplier Reference Separator** fields are visible in the *General* fast tab. These fields are used to control whether and how a reference is created. As column separators *Colon* and *Hyphen* are available for selection. :::warning Visibility of fields In addition, the **Supplier Reference** and **Supplier Reference Part 1-7** fields are available in the **Import Price List** page. ::: Using the **Supplier Reference** and **Supplier Reference Part 1-7** fields, you can either import a *complete* unique reference for an item or assemble it using multiple parts. :::tip Sequence of the fields If the reference is to be generated, the sequence of the parts is determined on the basis of the fields **Supplier reference part 1-7**. The fields are filled according to the Data Exchange Definitions (in the fast tab *Column Definition*). ::: ### Catalog item If a supplier reference exists or is created during processing, no **Manufacturer Item No.** is required. The rest of the processing does not differ from that for importing price lists without a supplier reference. The only difference is that in addition to **Manufacturer Item No.**, **Supplier Reference** is also a criterion for whether a new catalog item is created or an existing one is updated. In addition, the **Supplier Reference** is also visible in the price information (fast tab *Lines*) within a catalog item. ### Item When creating an item based on a catalog item, additional [vendor references](https://learn.microsoft.com/en-us/dynamics365/business-central/ubb/masterdata/references) are created for each vendor linked to a [Usage Data Supplier](https://learn.microsoft.com/en-us/dynamics365/business-central/ubb/masterdata/suppliers). This linking is done via the **Vendor Name** field on the usage data supplier. :::warning Missing link References for vendors are only created for those Usage Data Suppliers that are linked to a vendor. ::: --- ## Setup(Pli) # Setup Import Template **DYCE Price List Import** allows you to import price lists from different vendors into Microsoft Dynamics 365 Business Central very easily. The price list can be filtered during import and individual fields can be filled or replaced with specified values. The filter and field mapping are defined in an **Import Template**. A template can be created for each supplier and price list. This allows to process different, extensive price lists with just a few clicks. The import templates are **Data Exchange Definitions**. :::tip Item Templates The **Item Templates** contain DYCE-specific fields so they can be easily predefined for new master data records. ::: ## Data Exchange Definitions A new **Data Exchange Definition** can be created in the page with the same name. The page can be opened using the search (*Alt+Q*). Select *Import Price List* in the **Type** field after creating a new Data Exchange Definition. Otherwise, the Data Exchange Definition cannot be used to import price lists. The selection predefines some fields and creates a **Line Definition**. - The **File Type** is set to *Variable text*. - In the **Line Definition**, existing lines are deleted and a new one is created for importing the price list. - A **[Field Mapping](#field-mapping)** with the **Table ID** of the *Import Price List* (70112401) and the codeunit for processing files in CSV format (Reading/Writing XMLport - 70112401). :::tip file format Please check if the **File Encoding** and **Column Separator** match the file to be imported (CSV format). After **Import Price List** is selected, the fields may not be editable until the page has been refreshed or closed and reopened. ::: ### Column Definition The **Column Definition** specifies which column of the import file contains which information. A detailed description of how to set up Data Exchange Definitions can be found here. :::info Example |Column No.|Name|Data Format|Data Type|Data Formatting Culture| |:--|:--|:--|:--|:--| |2|manufacturer item no.|text||en-US| |3|Valid from|date|dd.MM.yyy|en-US| |4|Purchase price|decimal|en-US| ::: ### Field Mapping The **Field Mapping** can be opened in the **Line Definitions** fast tab via the **Field Mapping** action (action group *Manage*). :::warning Attention If the **File Type** *Import Price List* has not been set in the Data Exchange Definitions, no field mapping has been created yet. Change the type to continue. In addition, the **Mapping Codeunit** *70112401* is entered with the selection of *Import Price List* (in the **Type** field). The fields **Pre-Mapping Codeunit** and **Post-Mapping Codeunit** remain empty. ::: The **Field Mapping** specifies which column of the import file (see. [Column Definition](#column-definition)) should be imported to which field in the **Import Price List** page. :::info Example |Column No.|Column Caption|Field ID|Field Caption| |:--|:--|:--|:--| |2|manufacturer item no.|5|Manufacturer Item No.| |3|Valid from|13|Valid from| |4|Purchase price|9|Unit Cost| ::: ### Import Rules Not all lines in a price list are relevant. In order not to have to edit the import file or the imported lines in a cumbersome way, **Filter** can be applied. Information, such as the *Vendor No.*, is usually missing in import files because the supplier cannot provide it. It can be added by defining a **Fixed Value**. **Filters** and **Fixed Values** can be used in combination to replace values depending on the content of the import file. The **Import Rules** field shows for each line in the **Field Mapping** page how many filters and fixed values are stored. Clicking on the number in the **Import Rules** field opens the **Edit Import Rules** page. In this page filters and fixed values can be deposited. #### Filters Filters are applied to the contents of the columns in the import file. In order to filter on the content in a column, it must be entered in the field mapping. Clicking on the number of import rules in the line will open the **Edit Import Rules** page. The **Filter** field is used to enter the filter criterion, by which the import file is to be filtered. The filters can be designed the same way any filter is used in [Microsoft Dynamics 365 Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/ui-enter-criteria-filters#entering-filter-criteria). If there is more than one filter (multiple lines), a logical ["OR"](https://learn.microsoft.com/en-us/dynamics365/business-central/ui-enter-criteria-filters#124-eitheror) is applied. This applies to multiple filters in one line as well as in different lines. If a column in the import file is to be filtered and the column is not to be imported, the **Filters only** field is used (*Field ID: 21*). :::info Example |Column No.|Column caption|Field ID|Field Caption|filter| |:--|:--|:--|:--|:--| |8|Description|6|Description|Business*| |8|Description|6|Description|Azure*| All lines starting with *Business* or *Azure* in the description will be imported. ::: #### Fixed Values **Fixed Values** are used to automatically fill in missing information in the **Import Price List** page. Fixed values are inserted in the Import Rules the same way filters are. :::info Example |Column No.|Column Caption|Field ID|Field Cation|Fixed Value| |:--|:--|:--|:--|:--| |8|Description|2|VendorNo.|10523| During import, the value *10523* is automatically inserted in **Vendor No.** in the **Import Price List**. The specification of the Column No. is a technical necessity. Which column is chosen has no effect here. ::: #### Combination of Filters and Fixed Values **Filters** and **Fixed Values** can be used in combination. The filter is applied first. All lines of the import file that match the filter are imported. The **Fixed Value** is then applied exclusively to these lines. This makes it possible to set different values in the same field for subsets of the imported lines. :::info Example |Column no.|Column name|Field ID|Field name|Filter|Fixed value| |:--|:--|:--|:--|:--|:--| |8|Description|8|Item Template Code|Business*|ITEM BC| |8|Description|8|Item Template Code|Azure*|ITEM AZ| All lines starting with *Business* or *Azure* in the description will be imported. In all lines that start with *Business* in the description, the value *ITEM BC* is set as Item Template Code in the **Import Price List** page. In all lines that start with *Azure* in the description, the value *ITEM AZ* is set as Item Template Code in the **Import Price List** page. If a line falls within the filter range of multiple import rules, the Fixed Value from the last applied import rule wins (e.g. Filter 1: Business*, Filter 2: B*). ::: ## General Ledger Setup In some industries, it makes sense to take the manufacturer with you through the business processes and evaluate them later if necessary. For this reason, the **Dimension Code for Manufacturers** field is added to the **Dimensions** fast tab. It is used to uniquely identify the dimension that represents the manufacturer. However, there are currently no other functions associated with this field. ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCEPRICELISTIMPALL (DYCE Price List Import Read)** This permission set can be assigned to all users. It includes read-only permissions to use the components of **DYCE Price List Import**. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCEPRICELISTIMPUSER (DYCE Price List Import Edit)** This permission set is for all users importing and processing price lists. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCEPRICELISTADMIN (DYCE Price List Import Admin)** This permission set is designed for administrators and power users who should additionally be able to make adjustments to the import rules. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information on permission sets, see this part of the Microsoft documentation. --- ## Bundles(Srb) # Bundles and formatting Bundles can be used in **Sales Quotes**, **Sales Orders** (from here on called *sales documents*) and in **Customer Contracts**. This is an aggregation of individual components into a standalone product. In addition, formatting can be used to control what content and how that content is output on print documents. Bundles and formatting are part of the app **[DYCE Easy Bundle Seller](/docs/ht/welcome.md)**, which comes with **DYCE Subscription & Recurring Billing**. Bundles can be predefined based on [master data](/docs/ebs/bundles.md#master-data-for-bundles) or created [individually (on-the-fly)](/docs/ebs/bundles.md#creating-a-custom-bundle). ## Bundles and Service Commitment Items Items with Service Commitments and Service Commitment Items can be assigned as components to a Bundle in Sales Quotes and Orders. In **Sales & Receivables Setup** in the **Bundle** tab, you can set whether Service Commitment Items should be included in the calculations of a Bundle. If the option *Exclude Price/Discount/Amount* is selected in the **Service Commitment Item in Bundle** field, Service Commitment Items are not included in the calculation of Bundle price, discount and amount. With the option *Include Price/Discount/Amount*, Service Commitment Items are included in the calculation of Bundle price, discount and amount. :::warning Attention If the Bundle consists of a mixture of Service Commitment Items and other items, the Service Commitment Items are not automatically marked as *invoiced* upon shipment. When the Bundle is invoiced, the Service Commitment Items are included in the invoice with price 0. ::: ## Shipping a bundle Based on the **Service Commitment Option** of the component, a bundle greatly affects how a sales order can be shipped. * **Sales without Service Commitments** Item shipment behaves identically with and without a bundle. * **Sales with Service Commitments** As components in a bundle, shipment is possible only in the correct quantity ratio. The quantity ratio refers to all components with Service Commitment Option *Sales with Service Commitment* and *Service Commitment Item*. These components must be shipped in a way that they make up whole bundles. For example, if a third-party license and a proprietary license are combined as a bundle, the two licenses must be delivered in a ratio that results in a whole bundle. If exactly one third party license is sold for each own license, one third party license must be shipped at the same time for each own license. In the order, **Qty. to ship** is predefined accordingly. * **Service Commitment Item** A component with the Service Commitment Option *Service Commitment Item* behaves like the Service Commitment Option *Sales with Service Commitments*. It is important to note that **Qty. Invoiced** is not automatically set on delivery unless the bundle consists solely of Service Commitment Items. The bundle is saved when the shipment is posted so that it can be transferred to the Customer Contract. When transferring a Service Commitment from the bundle to a Customer Contract, the bundle is automatically created and all components are transferred. :::info The quantity of components can not be changed, once a component has been shipped. The quantity of the bundle can still be adjusted after shipment. The **Bundle Qty. Shipped** and **Bundle Qty. Invoiced** are displayed in the bundle. ::: ## Invoicing bundles in Sales documents In the sales order, the bundle is treated as an independent product during billing. It can only be billed when it has been shipped before. Components in a bundle cannot be billed independently. I.e. only as many bundles can be invoiced as whole bundles were shipped. If a bundle consists of two components and only one is delivered, it is not a complete bundle and therefore cannot be invoiced. If both components are delivered, the bundle can be invoiced. Accordingly, **Qty. to invoice** is set in the components so that bundles are always invoiced as a whole. If a bundle consists of **Service Commitment Items** only, it does not need to be invoiced. On shipment, the components are automatically entered as invoiced. :::info If a component is to be explicitly invoiced individually, the bundle can be dissolved at any time. To dissolve the bundle, either the bundle line must be deleted or the indicator *Bundle* must be removed. The bundle cannot be reassembled after release. New sales lines must be created for the quantities not yet delivered and a new bundle must be created. If a bundle was released that had a Service Commitment Item as a component, that Service Commitment Item is not billed. If the order is billed, **Qty. invoiced** is set in the Service Commitment Item, but no invoice is created because the invoice amount would be 0. ::: ## Using bundles in the Customer Contract The functionality and handling of [bundles](/docs/ebs/bundles.md) and [Formatting](/docs/ebs/formatting.md) are explained in detail in the corresponding parts of the DYCE documentation. Therefore, this section only covers the specifics regarding Customer Contracts. ### Creating individual bundles The procedure to create a bundle in a Customer Contract follows the same method as described [here](/docs/ebs/bundles.md) for sales documents. The exception is that in **Customer Contracts** the quantity of components cannot be changed. In addition, the page for editing a bundle can be accessed using the **Edit Bundle** function in the line menu (*Contract Line* in Customer Contracts). ### Prices and discounts in the bundle Unlike sales documents, Customer Contracts do not allow you to edit the price, discount, and amount in the bundle. :::warning Attention In Customer Contract, contract lines with different **Next Billing Date** and **Billing Rhythm** can be combined into one bundle. Therefore, the price calculation in the bundle does not include these factors. Thus, the bundle is not suitable for combining contract lines with different **Next Billing Date** and **Billing Rhythm**. ::: ### Invoicing bundles in Customer Contracts In Customer Contracts, the bundle is treated as a subtotal. Price, discount and amount from the bundle are calculated in the contract and transferred to the invoice during billing. In the invoice, the bundle is calculated again. The bundle is created as a text line in the invoice. Below the components are created. The entry from the **Service Object Description** in the contract is copied to the description of the document line. Below the bundle line, the **Billing Period** of the bundle is output as a text line. The billing period of the bundle corresponds to the earliest to latest billing period of the components. The billing period of the individual components is not created as a text line. :::warning Attention If two contract lines are to be assigned to a bundle, the **Next Billing Date** and the **Billing Rhythm** must be the same. The bundle amount refers to the complete **Billing Rhythm**. If a different period is selected during billing, the amount from the bundle will be recalculated in the invoice. ::: ## Dimensions in bundles In sales documents, dimensions can be stored directly on the bundle. In **Customer Contracts**, no dimensions can be stored on the bundle. The behavior of dimensions for bundles can be controlled for sales documents in the **[Sales & Receivables Setup](/docs/ebs/setup.md)** page in the **Dimensions** fast tab using the **Dimension Priority Bundle** field. :::warning Attention In the Customer Contract, dimensions can only be stored on the components and not the bundle itself. ::: ## Formatting Formatting can be used to control which contents and how these contents are output on print documents. This control allows, among other things, the printing of headings and hiding of components. For more information on formatting, please refer to [this](/docs/ebs/formatting.md) part of the DYCE documentation. --- ## Controlling # Evaluations ## Dimension Value for Customer Contracts In the **[Service Contract Setup](/docs/srb/setup/general.md)**, **Autom. Insert Cust. Contr. Dimension Value** controls whether the Customer Contract No. is automatically created as a new dimension value for each new Customer Contract. This is then automatically assigned to the respective contract. ## Dimension Value for Customers In the **[Sales & Receivables Setup](/docs/srb/setup/general.md#sales--receivables-setup)** it is controlled via **Autom. Insert Cust. Dimension Value** whether the customer number is automatically created as a new dimension value for each new customer. This is then automatically assigned to the respective customer. ## Other dimensions * **Customer Contract** The **Dimensions from Project No.** field can be used to fetch the dimensions from the specified Project into the respective Customer Contract via lookup. * **Customer Contract Line** * Dimensions are basically stored at the Service Commitments, but are accessible via the contract lines. When assigning Services Commitments to a Customer Contract, the dimensions of the Customer Contract header are passed to the Service Commitments. Additional dimensions are added and Dimension Values of existing dimensions are overwritten. However, no dimensions are deleted. * In addition, when assigning services to a Customer Contract and updating the dimensions at the Service Commitments a check is performed whether there are any vendor Service Commitments that refer to the same Service Commitment Template. If such a vendor Service Commitment is found, the dimensions of the Customer Contract Header are also passed to the vendor Service Commitment(s). * When deleting a contract line, the dimensions of the Customer Contract Header are removed in the related Service Commitments. * When changing a dimension in the Customer Contract Header (changing a Dimension Value, adding a Dimension, removing a Dimension), this change will be transferred to the Service Commitments on request. Here the system behaves in the same way as for sales documents. * **Vendor Contract Line** * When assigning Services Commitments to a Vendor Contract, the dimensions of the Vendor Contract header are transferred to the Service Commitments. Additional dimensions are added and Dimension Values of existing dimensions are overwritten. However, no dimensions are deleted. * When deleting a contract line, the dimensions of the Vendor Contract Header are removed in the related Service Commitments. * When changing a dimension in the Vendor Contract Header (changing a Dimension Value, adding a Dimension, removing a Dimension), this change will be passed to the Service Commitments on demand. * **Service Object** * The item to be used for billing (i.e. the Service Commitment Item itself or an Invoicing Item) is stored in the Service Commitment. The dimensions that this item brings are transferred to the Service Commitment. * Since the Service Commitment is kept in sync with the contract line, changes to the Service Commitment are also made to the contract line. * **Sales Service Commitments** * The item to be used for billing (i.e. the Service Commitment Item itself or an Invoicing Item) is stored in the Sales Service Commitment. The dimensions that this item brings are transferred to the Sales Service Commitment on shipment. * The remaining dimensions are copied from the Sales Line to the Service Commitments on shipment. If there is a dimension conflict, the dimensions of the item in the Service Commitment have higher priority. * **Recurring Billing** * There are no dimensions on the lines in **Recurring Billing**. However, the **Contract Line Dimensions** call can be used to access the dimensions of the related contract line. * When Posting Documents are created, the dimensions of the respective contract line are transferred to the corresponding document line. * **Contract Deferrals** * When posting the document line, the dimensions are transferred from the document line to the deferrals. * It is possible via the action **Update Dimensions in Deferrals** to update the dimensions in all Contract Deferrals for a contract that have not yet been released, e.g. if the dimensions of a contract line has been changed. * **Archived Billing Lines** * There are no dimensions in the Archived Billing Lines. ## Info box Contribution Margin To answer the question whether a contract with a customer is profitable, the contribution margin of the contract has to be considered. ***In the near future*** it will be possible in DYCE that this consideration of the economic viability per Customer Contract will be displayed clearly in the form of an info box. Furthermore, it will also be possible to cumulatively transfer this view to all Customer Contracts of the customer. Further evaluations of contracts will follow. --- ## Features # Features of DYCE Subscription & Recurring Billing ## Master data * Create Service Commitment Templates * Combine Service Commitment Templates to Service Commitment Packages * Assign Service Commitment Packages to items * Display Service Commitments at items * Role Center and Profile * Creation of bundles * Setup wizard - in planning * Service Commitment Package creation wizard - in planning ## Sales * Use of an item incl. Service Commitments in sales documents * Selection of optional Service Commitments in the sales process * Automatic pricing for Service Commitments * Editing Service Commitments in sales process * Creation of bundles on-the-fly * Formatting of sales lines * DYCE layouts for standard reports with output of Service Commitments when printing * DYCE layouts support formatting and bundles * Automatic creation of Service Objects on shipment * Position numbers in sales documents * Print preview of unposted sales documents * Pre-selection of the contract for billing in sales process - in planning * Use of bundles (master data) * Merging of Service Commitment Package Lines - in planning * Change sorting of document lines - in planning * Create Sales Quotes to renew Contract lines and Service Commitments ## Contract management * Customer Contracts and Vendor Contracts * Contract types * Assigning Service Commitments to a contract * Formatting of contract lines * Quantity changes * Price changes * Assign processor per document * Display open and posted documents for a contract * Do not show closed contract lines * Main due date per contract * Merge contract lines * Change sorting of contract lines - in planning * Move Service Commitments between contracts - in planning * Store and view contract documents on the contract - in planning * Archiving of changes to Service Commitments ## Contract billing * Overview of the Service Commitments to be billed as Billing Proposal with details * Creation of contract invoices in batch * Contract invoice accompanying list with billing details * Contract credit memos * Billing of single contracts * Automatic generation of Billing Proposals - in planning ## Usage-based billing * Import and processing of usage data - in planning * Scale prices (also for usage data) - in planning * Several customer-side price calculations - in planning * Connectors to manufacturers - in planning ## Monitoring * Monitoring of Cancellation Periods and Service End Dates * Automatic updating of cancellation periods and deadlines * Notice for Service Commitments not yet assigned to a contract * List all Service Commitments, which need to be renewed ## Contract Deferrals * Periodic customer and vendor deferrals * Automatic release of deferrals * Output of deferrals ## Contract evaluation * Automatic dimension per contract * Automatic dimension per customer * Cost-revenue analysis per contract - in planning * Dimensions for Service Commitments --- ## First Steps # First steps By signing a contract, both partners assume obligations. In DYCE, these obligations are referred to as Service Commitments. Agreements with periodic billing are called **Customer Contracts** on the customer side and **Vendor Contracts** on the supplier side. Service Commitments can already be offered to the prospect or customer during the [sales phase](/docs/srb/sales/sales-service-commitments.md). For this purpose, additional Service Commitments can be added to the offered items which can then be offered simultaneously or sold at the same time. If an item is sold in conjuction with a Service Commitment, a [Service Object](/docs/srb/working-with-contracts/service-objects.md) is automatically created for it, where the associated Service Commitments are visible. If the service is a *[Service Commitment](/docs/srb/masterdata/service-commitments.md)* (see *Types of Services*), it can be added to a contract as a component and - according to the information in the service - be billed on a recurring basis. ## Use of Service Commitments ![](/img/srb/ProcessOverview.png) ## Role Center In order to find most calls as fast and easy as possible, the Role Center **Subscription & Recurring Billing** is available especially for this purpose. In addition to the master and transaction data, the **[Recurring Billing](/docs/srb/recurring-billing.md)** and the history of posted receipts can also be called up from here. In addition, documents that have not yet been posted (**Open Posting Documents Customer/Vendor**) and services that have not yet been assigned to contracts (**Services Commitments without Contract**) are displayed, thus alerting the user that something may still need to be done here. **Revenues and Costs** show the current and previous month's revenues and costs posted in connection with contract billing. The cues **Overdue** and **Not invoiced** indicate that Service Commitments - related to the workdate - are either still to be billed (*Overdue*) or that no [posting document](/docs/srb/posting-documents.md) has been created yet (*Not invoiced*) for lines in a [billing proposal](/docs/srb/recurring-billing.md). Via **Help & Support** (the *?* in the upper right corner) [this](/docs/srb/welcome.md) online help can be started. --- ## Glossary The most important DYCE terms can be looked up in this glossary. ## A * **Additional Service Commitments** Service Commitments that can be selected in addition to the standard Service Commitments. ## B * **Billing Base Period** The period of time to which the Service Amount applies. For example, enter 1M here if the amount refers to one month or 12M if the amount refers to 1 year. * **Billing Date** The cut-off date by which Service Commitments to be billed will be considered. * **Billing line** Shows the history of billing contract lines. When posting recurring bills, they are created from the Billing Proposal Lines. * **Billing Proposal** The billing lines created using one or more Billing Templates form a Billing Proposal. This is the basis for creating the contract invoices. * **Billing Proposal Lines** Are a preview of billing lines. Lines for the same contract line and different billing periods are combined in the invoice. * **Billing Rhythm** Specifies the rhythm at which the Service Commitments will be billed. A Dateformula can be used to set the rhythm to, for example, monthly, quarterly or annual calculation. * **Billing Template** The Default name used to determine the Service Commitments to be billed. * **Bundle** A bundle is a combination of individual components into a stand-alone product. ## C * **Calculation Base %** The percentage at which the price of the Service Commitments is calculated. 100% means that the price of the service is equal to the Calculation Base Amount. * **Calculation Base Amount** The basis on which the price is calculated. * **Calculation Base Type** Indicates how the Service Commitments price is calculated. "Item Price" uses the list price that is stored on the item. "Document Price" uses the price from the sales document. "Document Price And Discount" uses the price *and* discount from the sales document. * **Contract** This refers to customer and vendor contracts. * **Contract Deferrals** Costs and revenues that are posted in a specific period but relate to a future period can be deferrals. These deferrals can be displayed across the board or per contract. * **Contract line** Services Commitments assigned to a contract automatically create contract lines. These are billed via Recurring Billing. * **Contract Type** Indicates the classification of the contract. * **Contractor** Customer or supplier for whom the contract is created. * **Credit Memo Preview** Function for creating a print preview for an unposted credit memo. * **Customer Contract** Customer Contracts can be used to retrieve and process customer-side Service Commitments before they are subsequently billed to the appropriate customers. ## D * **Detail Overview** Specifies whether the billing details for the contract are automatically output with invoices and credit memos. ## E * **End User** The End User is the customer to whom the Service Commitments were sold. This can be entered in the Service Object. ## I * **Initial Term** The Dateformula used to calculate the minimum term of the Service Commitments. If the Initial Term is filled and no Subsequent Term is entered, the Service End Date will automatically be set to the end of the Initial Term. * **Invoice Preview** Function to create a print preview for an unposted invoice. * **Invoicing Item** An item so identified is used for billing additional Service Commitments sold for another item. * **Invoicing Item No.** Indicates (in the Service Commitment Package Line) which item in the contract invoice is used to bill for the periodic service. * **Invoicing via** Indicates (in the Service Commitment Package Line) whether the service is billed via a contract or sales document. ## N * **Next Billing Date** Indicates (in the Service Commitments and contract lines) the date of the next possible billing. ## P * **Position Number** A number or designation can be entered in each position in sales documents. The Position Numbers will be printed. * **Posting document** This is an invoice or credit note that has not yet been posted. * **Price Group** Specifies the customer price group (e.g., in the Service Commitment Package) that will be considered in pricing the Service Commitments. ## R * **Recurring Billing** This page will first create the Billing Proposal and then the posting documents. * **Released** Revenues and costs for contracts are deferred by default (and under certain conditions). If the deferrals were released this is marked accordingly. * **Report Configurations** Used to configure for the document footer. * **Role Center** Home page in Microsoft Dynamics 365 Business Central ## S * **Sales Service Commitment** This refers to services that are part of a line in the quote or order. * **Service Amount** Indicates the amount of a Service Commitments minus the discount granted. * **Service Commitment** Service Commitments represent obligations to customers and vendors. * **Service Commitment Item** ...may be used in sales documents, but are charged exclusively through contracts. * **Service Commitment Option** Indicates whether a Service Commitments can be deposited for an item or whether it is an item for billing services. * **Service Commitment Package** This is used to bundle Service Commitment Package lines and manage price groups. Service Commitment Packages can be stored on items. * **Service Commitment Package Line** Specifications for Service Commitments are defined using the Service Commitment Package Line. When the item is entered in a quote or order, the specifications from the Service Commitment Package Line are applied to the service. * **Service Commitment Start Formula** Specifies the date from which a Service Commitments is valid using a formula. Using this Dateformula, the validity can be automatically set to, for example, the first of the following month. If the field remains empty, the Service Commitments is valid from delivery. * **Service Commitment Template** Serves as the Default for a Service Commitment and can be selected in the Service Commitment Package Line. * **Service End Date** Indicates the date until which the Service Commitments is valid. * **Service Object** Service Objects represent a history of products sold to a customer. Service Commitments are created in Service Objects. * **Service Start Date** The date from which the Service Commitments are valid and charged. * **Subsequent Term** Specifies a Dateformula for automatic renewal after the Initial Term and the rate at which "Cancellation Possible Until" and "Term Until" are updated. If the field is blank and either the Initial Term or the Notice Period is set at the same time, the Service End Date is automatically set to the expiration date of the Initial Term or the Notice Period. ## U * **Update Service Dates** This action updates the cancellation dates. ## V * **Vendor Contract** Vendor Contracts can be used to retrieve and process vendor-side Service Commitments before subsequently creating vendor posting documents. --- ## Items # Service Commitments at Items Items can be set when being used they either bring additional service commitments with them or they represent service commitments themselves. The setting for this can be made via the **Service Commitment Option** field (in the *Prices and Sales* fast tab). Basically, four options are available: |Option|Meaning| |:--|:--| |Sales without Service Commitment|This selection means that the item is for sale only and not for Service Commitments or contracts. This setting is typically used for trade-only items. For items with this setting, *no* Service Object will be created upon delivery. This is also not possible manually.| |Sales with Service Commitment|This selection means that this item can be sold with additional service commitments. If additional service commitments are stored, these are used either automatically (**Default**=*YES* in assigned Service Commitment Package) or on request in the sales process. For items with this setting, a Service Object is created *automatically* upon delivery. |Service Commitment Item|This selection means that this item can be used in a sales document, but Invoicing is done exclusively (in the form of Service Commitments) via the contract. When a Sales Order line is delivered, it will automatically be set as *Invoiced*. This option can only be selected if **Type**=*No Inventory*. For items with this setting, a Service Object is created *automatically* upon delivery. |Invoicing Item|This selection means that this item will be used for billing additional service commitments sold for another item. This option can be selected only if **Type**=*Non-Inventory*. This item cannot be used in document lines (Sales Quote / Sales Order / Sales Invoice / Purchase Invoice). No Service Object *can* be created for items with this setting. ## Service Commitments (Infobox) The Service Commitments stored on an item are displayed in the infobox area via the infobox of the same name. This infobox is available in the Item list as well as in the Item card. In addition to the name of the Service Commitment Package, the infobox also shows whether the respective Service Commitment Package is marked as *Standard*. If an item set in this way is used in the sales process, all the services from the corresponding Service Commitments Packages are transferred to the sales item in the document (see [Assign Services](/docs/srb/sales/sales-service-commitments.md)). Clicking on the header of the infobox opens the **Service Commitment Packages per Item** page. Here, the overview of all Service Commitment Packages stored for the item (upper part) including the respective details (Service Commitment Package Lines, lower part) is displayed. For visual assignment, the Service Commitment Package Lines for the currently selected package are displayed in bold. This is particularly helpful if several Service Commitment Packages are stored for the item. Insert the Service Commitment Package in a new line to add it to the item. If a line is deleted, the Service Commitments will not be available in Sales Orders or Quotes anymore. ## Service Commitments (Action) Analogous to the Infobox, the Service Commitments stored on the item can also be called up via the **Service Commitments** action. The call is located in the **Item** action group and is available both in the Item list and in the Item card. --- ## Service Commitments Service Commitments represent obligations to customers and suppliers. They usually begin with the delivery of an item to the customer, include subsequent support, and govern billing arrangements. A Service Commitment can also be the subject of provision itself, e.g. in the case of a support service. During the sales process, all relevant information about appropriately set up items is collected and stored in the form of a Service Object. The Service Object is created automatically when the item is delivered (posting of Sales Shipment). Service Commitment Templates and Service Commitment Packages are available for mapping and setting up Service Commitments. Service Commitments are grouped into Contracts (Customer and Vendor Contracts) for management and billing purposes. Service Commitments include the details of the obligations that the supplier of a product assumes towards its customers, which in turn are covered by its supplier, if applicable. ## Warranty When a product is sold, a warranty is required by law. This means that the supplier of a product guarantees that the products it supplies have the promised properties. The warranty is usually limited in time. The statutory warranty is usually supplemented by a Service Commitment, i.e. manufacturers grant the customer an extended warranty period from the date of purchase or even Service Commitments that go beyond what is legally indispensable, for example free on-site replacement of defective parts. Since a Service Commitment represents the mapping of these commitments, it contains all relevant service agreements, such as prices, validity periods, cancellation periods, and the billing rhythm. In order for a Service Commitment to be billed (recurringly), it must be assigned to a contract. The Contract No. is then displayed in the Service Commitment. ## Use of Service Commitments ![](/img/srb/ProcessOverview.png) ## Service Commitment Templates Service Commitment Templates can be created optionally. They are used to simplify the creation of Service Commitment Packages or their details (lines). The interrelationships of the fields are explained in the [Service Commitment Packages](#service-commitment-packages). ## Service Commitment Packages Service Commitment Templates are grouped into Service Commitment Packages. These can then be firmly assigned directly to the items (via the call **Assigned Items**). At the time of delivery, the variable parameters (e.g. price calculations and durations) are converted into absolute values and attached as Service Commitments to the sold item (Service Object). A Service Commitment Package corresponds to the unit that is offered and sold to the customer. In a Service Commitment Package, both the service liabilities to the customer and the service receivables towards the own suppliers can be stored. The example of the legal warranty shown below illustrates this, as here the customer can make claims within the specified period, but these are simultaneously covered by Service Commitments towards the supplier. :::tip Copy Service Commitment Packages To simplify the creation of a Service Commitment Package, an existing Service Commitment Package can be copied using the **Copy Service Commitment Package** action and then customized. ::: ### Overview of the fields in the Service Commitment Package * In addition to the unique **Code** and **Description**, a **Price Group** can be stored. This allows a Price Group to be taken into account when pricing Service Commitments. For more details please see section [Price Group in Sales Service Commitments and Service Objects](#price-group-in-sales-service-commitments-and-service-objects). * **Partner** specifies whether a customer or vendor Service Commitment is to be created later. Accordingly, the Services Commitments can then be called into Customer/Vendor Contracts and invoiced via Purchase or Sales Invoices. * **Template** indicates whether the line was created based on a **Service Commitment Template**. Specifying a *Service Commitment Template* is optional - the line can also be entered manually. * **Description** specifies the description of the Service Commitment that will be created in further processing. * For explanation of **Invoicing via** see [Types of Service Commitments](#types-of-service-commitments). * For explanation of **Invoicing via Item No.** see [Control of revenue accounts](#control-of-revenue-accounts). * For explanation of **Calculation Base Amount Type** see [Pricing and calculation types](#pricing-and-calculation-types). * **Calculation Base Amount %** is the percentage of the **Calculation Base Amount** that is used in the sales process to price the Service Commitments. * **Calculation Base Period** specifies the period to which the Service Amount should subsequently relate. For example, enter 1M if the amount refers to one month or 12M if the amount refers to one year. * **Billing Rhythm** defines the frequency at which the Service Commitments should be billed later. * The Dateformula in the **Service Commitment Start Formula** field specifies the time offset at which a Service Commitment becomes valid. * **Initial Term** specifies the minimum term of the subsequent Service Commitments. If the Initial Term is populated in the sales process and no **Subsequent Term** is entered, the **Service End Date** is automatically set to the end of the Initial Term. * The Dateformula in the **Subsequent Term** field specifies the duration of the automatic extension after the Initial Term. If the field is blank in the sales process and either the Initial Term or the Notice Period is set at the same time, the Service End Date is automatically set to the expiration date of the Initial Term or the Notice Period. * The Dateformula in the **Notice Period** field specifies the lead time before a Service Commitments can be cancelled at a later date. A 12 month Initial Term with a 3 month notice period means that the due date for termination is reached after 9 months. * **Discount** is used to control whether the Service Commitment is used for discounts during periodic billing. * The **Price Binding Period** defines the period, in which the price will not be changed after the Service Commitment has been created. When the Service Commitment is created, the **Next Price Update** date is calculated from the **Service Start Date** and the **Price Fixing Period**. The field can be displayed using personalization. ### Example Partner|Template|Description|Invoicing via|Invoicing via Item No.|Calculation Base Type|Calculation Base %|Calculation Base Period|Calculation Base Rhythm|Service Commitment Start Formula|Initial Term|Subsequent Term|Cancellation Period |--:|--:|--:|--:|--:|--:|--:|--:|--:|--:|--:|--:|--:| Customer|Guarantee|Warranty|Sale||Item Price|0|12M||12M|| Supplier|Guarantee|Warranty|Sale||Item Price|0|12M||12M|| :::tip Service Commitment Packages in Item Templates To simplify the creation of items with Service Commitments, Service Commitment Packages can already be stored in the Item Templates. If an item is created using a template that includes Service Commitment Packages, these are automatically transferred to the new item. This is particularly useful if several items are created as [batch processing](/docs/pli/price-list.md#creating-and-updating-catalog-items) via **DYCE Price List Import**. ::: ### Dimensions If a Service Commitment Package contains lines with both Partner=*Customer* and Partner=*Vendor*, the [dimensions](/docs/srb/setup/general.md#dimensions) of the later [Customer Contract Line](/docs/srb/working-with-contracts/customer-contracts.md) are passed to the corresponding [Vendor Contract Line](/docs/srb/working-with-contracts/vendor-contracts.md). The decisive factor here is that the service package code is identical. This is primarily for evaluation purposes. ### Price Group in Sales Service Commitments and Service Objects Before the prices for the Service Commitments in the sales document can be calculated, the appropriate Service Commitment Package(s) must be determined - also on the basis of the price group, among other things. The following applies: * If the Service Commitment Package is not set in the document, only Service Commitment Packages *without* the price group are used. * If the Service Commitment Package is set in the document, *only* Service Commitment Packages with the same price group will be applied. If *no* Service Commitment Packages matching the price group are found, Service Commitment Packages *without* price group will also be considered. Service Commitment Packages that are set as default (**Default**=*YES*) for the item will be applied directly. Others will only be displayed. * If no Service Commitment Package *without* Price Group is found either, *all* Service Commitment Packages will be considered. Those that are set as the default package (**Default**=*YES*) for the item will be applied directly. Others are only displayed. * If no Service Commitment Package is found at all, no Sales Service Commitments will be created. The determination of Service Commitments when manually creating a Service Object is done in the same way as the creation and calculation of Sales Service Commitments. However, if the End User (Customer) in the Service Object is changed, the Service Commitments must be recalculated if the price group of the new End User (Customer) differs from the one in the Service Object. The user receives a corresponding query. If this is confirmed, the Service Commitments are deleted and recreated based on the above criteria. Otherwise, the End User (Customer) will be reset to the original value. :::note Note It is only possible to change the Service Commitments in the Service Object if none of the services are linked to a Customer Contract or Vendor Contracts. ::: ## Types of Service Commitments * **Contract** . A Service Commitment whose Default in the **Invoicing via** field is set to *Contract* will be brought to Invoicing via a defined cycle. Optionally, terms and notice periods can be stored for this. * **Sales** A Service Commitment, whose default in the field **Invoicing via** is set to *Sales*, will not be invoiced. The Service Object and Service Commitment does only serve as information (e.g. for the warranty period or the after-sale to a warranty). :::info Only Services Commitments whose template is set to *Contract* in **Invoicing via** can be assigned to an Customer or Vendor Contract and thus billed recurrently via that contract. ::: ## Pricing and calculation types Three types of reference values (*Item Price*, *Document Price* and *Document Price And Discount*) are used to price Service Commitments via the **Calculation Base Type** field. The details are explained [here](/docs/srb/sales/price-calculation.md). ## Control of revenue accounts Services that are (optionally) co-sold with an item (see [Sales with Services](/docs/srb/masterdata/items.md) in the **Service Commitment Option** field in the Item card) are usually handled by an *Invoicing Item*. Depending on the configuration of the posting groups in Financial Accounting, revenues can thus be posted to different revenue accounts for each Service Commitment to be billed. The lookup of the field **Invoicing via Item No.** is restricted to Invoicing Items. Services that are themselves the subject of provisioning (e.g., a support service) can also themselves contain the posting groups for revenue control (see [Service Commitment Item](/docs/srb/masterdata/items.md) in the **Service Commitment Option** field in the Item card). In this case, the **Invoicing via Item No.** field can also be left blank. --- ## Posting Documents Posting Documents are invoices and credit memos because these documents can be posted. When creating these documents via **[Recurring Billing](/docs/srb/recurring-billing.md)**, the system recognizes whether an invoice or a credit memo is to be created based on the amounts to be settled. If the total amount over all lines to be billed is positive, an invoice is created, otherwise a credit memo is created. This applies to both Customer Contracts and Vendor Contracts. The Posting Documents created are then available for calling up in the respective contract under **Related**. There are separate calls for documents that have not yet been posted and documents that have already been posted. Sales documents are created from Customer Contracts and purchasing documents from Vendor Contracts. The documents can also be called using the following methods: * **Sales Invoices** (Role Center or Alt+Q) . A filter *Recurring Billing* is available in the page, which displays only the documents that belong to a contract. * **Sales Credit Memos** (Role Center or Alt+Q) A filter *Recurring Billing* is available in the page, which displays only the documents that belong to a contract. * **Posted Sales Invoices** (Role Center or Alt+Q) A filter *Recurring Billing* is available in the page, which displays only the documents that belong to a contract. * **Posted Sales Credit Memos** (Role Center or Alt+Q) A filter *Recurring Billing* is available in the page, which displays only the documents that belong to a contract. * **Purchase Invoices** (Role Center or Alt+Q) * **Purchase Credit Memos** (Role Center or Alt+Q) * **Posted Purchase Invoices** (Role Center or Alt+Q) * **Posted Purchase Credit Memos** (Role Center or Alt+Q) For each document line, the details underlying the calculation can be accessed by calling **Billing Lines** (in the line menu via *Manage*). ## Additional information in contract invoices In order to be able to react to different needs regarding the order of the output of information in contract invoices, it is possible to specify via [Setup](/docs/srb/setup/general.md#invoice-details) at which position in the contract invoice which information should be output. It is possible to control the output of the names of the contractor and the service recipient as well as other information about Service Objects and Service Commitments. ## Invoice and Credit Memo Preview In addition to the **Preview Posting** from Business Central, DYCE also provides a [Print Preview](/docs/general/essentials/print-preview.md) for Sales invoices and credit memos that have not yet been posted. ## Post document Posting Documents for contracts can be posted and printed individually or in batches, as is usual in the purchasing and sales areas. Especially in the case of a large number of contracts, it makes sense to check the Posting Documents by batch after they have been generated, to post them in the batch and to print them in the batch. In addition, **[Contract Details](/docs/srb/working-with-contracts/customer-contracts.md#details-for-contract-invoices)** can be output per customer contract invoice. These show the details relevant to the customer's contract invoice broken down in an understandable way. When a document is posted, the associated billing lines are archived. These can be subsequently accessed via the posted document line (call **Archived Billing Lines** in the line menu via *Manage*) or the corresponding contract line (call **Archived Billing Lines** in the line menu via *Contract line*). :::note Posting Description in Customer and Vendor Ledger Entries When the documents are posted, the Posting Description in the Customer Ledger Entries and Vendor Ledger Entries can be used to trace from which contract the entry originates. If the document belongs to exactly one contract, the type of contract (Customer or Vendor Contract) and the Document No. are included. If there are multiple contracts, "Multiple Customer Contracts" or "Multiple Vendor Contracts" (each in the user's language) is used. ::: --- ## Purchasing The unique [purchase](https://learn.microsoft.com/en-us/dynamics365/business-central/purchasing-manage-purchasing) of items with Service Commitments is no different than that in Microsoft Dynamics 365 Business Central. Recurring purchasing (e.g., rental, maintenance, or subscription) is mapped with Service Commitments. Service Commitments receive *Vendor* as **Partner** in the Service Commitment Package. A Service Commitment Package can have both Customer and Vendor Service Commitments. ## Sales Quote and Sales Order Service Commitments behave in [Sales](/docs/srb/sales/sales-service-commitments.md) in the same way as Service Commitments that have *Customer* entered as **Partner**. Depending on the **Calculation Base Type**, the **Calculation Base Amount** is determined from the **Unit Cost** field in sales lines or the **Last Direct Cost** field in the item. For more details, see [price calculation](/docs/srb/sales/price-calculation.md). ## Service Object When the item is delivered from the order, the Service Object and its Service Commitments are created. Both Customer and Vendor Service Commitments can be entered in the Service Object. ## Assignment to a Vendor Contract Vendor Commitments can be assigned to any Vendor Contract. Unlike Customer Service Commitment, a Vendor Service Commitment can be assigned to any Vendor Contract. :::info In the **[Role Center](/docs/srb/first-steps.md)** you can see if there are any Vendor Service Commitments that have not been assigned to any contracts yet. ::: --- ## Purpose # Purpose and benefits of DYCE Subscription & Recurring Billing ## Contracts Contracts are used to group multiple Service Objects and their Service Commitments so that they can be billed together on a recurring basis. A contract in DYCE is the technical equivalent of one or more actual contract documents. A contract defines the commercial framework (contractual partners, invoice recipients, accounting conditions). Service Objects (and their Service Commitments) represent the components of the contract. ## Service Objects A Service Object is something that the customer either buys or for which a contractual agreement is concluded, resulting in mutual obligations. A Service Object can thus be clearly assigned to a customer. The Service Object is usually static, but the associated Service Commitments can change. Furthermore, additional information can be stored in the Service Object that is independent of the Service Commitments themselves. The Service Object itself does not contain any billing-relevant information - this belongs to the associated Service Commitments. Service Commitments that are not invoiced via a contract can also belong to a Service Object. ## Service Commitments Service Commitments describe the content of agreements with customers and suppliers. They exist in customer-side and vendor-side form and always belong to a concrete Service Object. In addition, they contain billing information such as the quantity to be billed, the billing period and the amount. The Service Commitments of a Service Object and the creation of these Service Commitments are defined via a multi-level hierarchy. It includes Service Commitment Templates and Service Commitment Packages that can be assigned to items. Service Objects are created via the sale of these items, to which the associated Service Commitments are visible. --- ## Recurring Billing Contracts are billed via the **Recurring Billing** page. First a Billing Proposal is created, based on which the **[Posting Documents](/docs/srb/posting-documents.md)** (invoices and credit memos) are created in a second step. The billing or the creation of the Billing Proposal is based on the contract lines, taking into account the **Next Billing Date** field (see [Overview of Fields in Service Commitments/Contract Lines](/docs/srb/working-with-contracts/contracts-services-mgmt.md)). ## Structure of the working area The page is structured as follows: 1. **Filter area** - A **Billing Template** can be selected here. - The **Billing Date** is predefined by the Billing Template, but can be changed. It is used to suggest the appropriate contract lines for billing based on the **Next Billing Date** field (from the contract line). - Via the **Billing Rhythm**, each contract line brings the information up to which date it should be billed by default. Via the **Billing to Date** field, this can be specified (differently) for all lines to be created. This can result in the period to be billed being shortened or also extended. The field is also predefined via the Billing Template and can also be changed. By means of a limitation it could be achieved, for example, that contract items added during a fiscal year are only invoiced until the end of the year/fiscal year in order to have a uniform Billing Rhythm again for the next billing period. 2. **Actions** - **Create Billing Proposal** The action runs through all contract lines and suggests the Service Commitments to be billed based on the **Next Billing Date** and the **Billing to Date**. By changing the Billing Template and calling it again, additional lines can be added to the Billing Proposal. If the **Next Billing Date** is greater than the billing date, this line will be ignored. If the **Next Billing Date** is smaller than the Billing Date, the corresponding period (taking into account the Billing Rhythm) must be invoiced. - **Create Documents** The action creates Contract invoices or credit memos for the displayed lines for which no documents exist yet. - **Clear Billing Proposal** By calling this action, the Billing Proposal can be deleted. A query follows asking whether the entire Billing Proposal or only the lines added by the currently selected Billing Template should be deleted. - **Delete Documents** The action deletes all generated Contract invoices or credit memos for the displayed lines. - **Change Billing To Date** Via this action, the date in the **Billing To** field can be individually adjusted. At the same time, the **Service Amount** will be recalculated. The action is executed for all selected lines. - **Delete Billing Line** This action is used to delete all selected lines. - **Refresh** This action updates the lines, e.g. if warnings are displayed there. If the reason for the warning is not given anymore, the warning is withdrawn. - **Navigate** - *Customer / Vendor* The action opens the customer or vendor card of the current line. - *Contract* The action opens the contract card of the current line. - *Service Object* The action opens the Service Object of the current line. - *Contract Line Dimensions* This action can be used to view the dimensions stored on the associated contract line. 3. **Billing Proposal Lines** - The Billing Proposal lines show the details of the lines to be billed. - In addition to the contractor and the contract, information about the Service Object and the Service Commitments to be billed is also displayed. - When **Create Billing Proposal** is called, one or more lines are created for each Service Commitments based on the **Next Billing Date** and the **Billing to Date**. Multiple lines are always created if the **Billing Rhythm** of the contract line fits several times into the period between **Next Billing Date** and **Billing to Date**. Each line displays information regarding the billing period (**Billing from** and **Billing to** fields) and the prices (**Service Amount**, **Price**, **Quantity** and **Discount** fields). Using this method, no contract line to be billed can be overlooked (as long as the filter criteria from the Billing Template are correct), as all past contract lines are automatically part of the filter. - It is possible to define a grouping for the Billing Proposal in the **Billing Template** ([see next section](#billing-templates)). If a grouping is set in the currently selected Default, the Billing Proposal lines can be expanded and collapsed based on this criterion. This is done using the double arrow next to the **Partner Name** heading. In addition, individual blocks can also be expanded and collapsed. This is done using the single arrow next to the **Partner Name** field in the line. - If a posting document (invoice or credit memo) has already been created, it is displayed via **Document Type** and **Document No.**. A click on the Document No. opens the posting document. :::tip Extend Billing Proposal By changing the Billing Template and calling **Create Billing Proposal** again, the Billing Proposal can be extended piece by piece. In this way, for example, collective invoices can be created for several contracts, although the contracts are found via different Billing Proposals. ::: ## Billing Templates By clicking on the AssistEdit in the **Billing Template** field, all available Billing Templates will be displayed. Each Billing Template requires a unique code and description as well as filter criteria and date calculation defaults. The date calculation defaults are specified in the form of date formulas. The actual date values are then calculated based on the working date when a Billing Template is selected/applied. This allows the defaults to be used over and over again. The **Partner** field is used to specify whether this default is used to bill customer (*Customer* value) or vendor (*Vendor* value) Service Commitments. In order to use a Billing Template, filter criteria must be entered, which will then be used to determine the Service Commitments to be billed. To define the filters, the **Edit Filter** action is called. A *filter page* opens where the criteria can be defined. In addition to the pre-set criteria, further criteria like the Contract Type, the responsible officer or the salesperson can be added (via *+ Filter...*). If the *filter page* is left via *OK*, the criteria are saved in the Billing Template. This is to be recognized by the fact that in the field **Contract filter** a hook is set. In the **Billing Date Formula** field, a Dateformula is entered that will be interpreted when the Billing Template is used in the **Billing Date** field. This field is then used to filter the Service Commitments to be billed (based on **Next Billing Date**) when creating the proposal lines. If no Dateformula is specified, the **Recurring Billing** will use the Work Date. The **Billing To Date Formula** field can optionally be used to enter a Dateformula which, if present, will be interpreted when the Billing Template is used in the **Billing To Date** field. This field is then used to set the end date of the billing in the Service Commitments to be billed. If no Dateformula is specified, the field in **Recurring Billing** will also remain empty and the lines will be proposed based on the information in the contract line. The **My Suggestions Only** field can be used to filter the Billing Proposal to those lines created by the user. The **Group by** field controls whether the lines in the Billing Proposal are displayed in groups. In addition to no grouping, the *Contract* and *Contract Partner* selections are available. If *Contract* is selected, all billing lines of a contract will be displayed grouped. The grouping level is displayed in bold. In addition, the **Billing From** and **Billing To** fields display the total (grouped) period and the **Service Amount** field displays the total of the associated Service Amounts. :::important Billing Proposals with multiple users Each contract line can be included in a Billing Proposal only once per billing period. If a billing line for a period has already been created by *another* user and the current Billing Proposal uses a default in which the **My Suggestions Only** indicator is set, the *current* user cannot create that line again for *themselves*. ::: ## Create Posting Documents Once the Billing Proposal has been created, the **Create Documents** action can be used to create the invoices or credit memos for the displayed lines for which no documents exist yet. The page of the same name opens, where specifications for the documents to be created can be made. For example, both the **Document Date** and the **Posting Date** can be specified. Optionally, the created documents can also be posted directly (**Post documents**). In addition, **Documents per** can be used to specify whether the Posting Documents are to be created per *Contract*, per *contract Partner* or per *Invoice recipient*. * **Contract** A separate invoice is created for each *contract*. Thereby all defaults from the respective contract are taken over. * **Contract Partner** Invoices are created for each *Contract Partner*. Payment Terms, Payment Method etc. are taken from the Customer. Invoices are only created separately for the contracts if the currency or the *[Detail Overview](/docs/srb/working-with-contracts/customer-contracts.md#details-for-contract-invoices)* in the contracts differ. * **Invoice Recipient** Invoices are created for each *Invoice Recipient*. Payment Terms, Payment Method etc. are taken from the Customer. Invoices are only created separately for the contracts if the currency or the *[Detail Overview](/docs/srb/working-with-contracts/customer-contracts.md#details-for-contract-invoices)* in the contracts differ. Further details on the Posting Documents created are explained in more detail [here](/docs/srb/posting-documents.md). :::tip In-advance and post-invoicing Contract lines to be invoiced in advance and in arrears can be proposed for invoicing via different Billing Templates, if required. This is possible through the interaction of **Next Billing Date** and the **Billing Date**, provided that no **Billing To** date is used. Alternatively or additionally, the contracts to be billed differently can also be distinguished from each other using different **[Contract Types](/docs/srb/setup/contract-types.md)**. The Contract Type can be used as a filter criterion in the Billing Templates. ::: ## Need to update The **Recurring Billing** is equipped with a multi-level mechanism to prevent data inconsistencies. If changes of any kind are made to a Service Commitment or contract line while lines are already created in the Billing Proposal, those lines will be highlighted twice in the Billing Proposal. On the one hand, the lines are displayed in red and bold and, on the other hand, they receive an indicator in the **Update Required** field, which shows that an update of the lines is necessary. When updating, the changed values are taken from the Service Commitments or the contract lines. The update can be done by executing one of the actions **Create Billing Proposal** or **Refresh**. As long as the update has not been performed, no Posting Documents (invoice / credit memo) can be created. If an unposted document already exists, no changes can be made to the Service Commitments or contract lines. A corresponding error message will appear. Only changes that are *not billing relevant* can be made in the posting document itself. For example, changes can be made to the description of the lines or new lines can be added. For all other changes, the posting document must first be deleted, the changes made to the contract line (or Service Commitments), then the billing lines updated and the document recreated. In addition, it is not possible to create multiple Posting Documents for the same billing line. :::note Updating the contract lines The moment a Billing Proposal is created for a contract line, the **Next Billing Date** field is immediately updated. It therefore *always* shows the current status. If the billing line is deleted (or the billing period is changed), the field is automatically reset (or set based on the changed billing period). A credit memo to a contract invoice will also reset the **Next Billing Date** field. To ensure consistency of the contract line and Service Commitments, when crediting multiple contract invoices, the credits must be chronological. ::: --- ## Credit Memos and Cancellation # Credit Memos If a contract invoice contains incorrect information, such as incorrect customer information due to a name change, the invoice can be credited. Once credited, the information in the contract can be corrected and the invoice recreated. If a customer cancels a service, this can be maintained in the contract line. Once the contract line is terminated, it will no longer be billed. If [deferrals](/docs/srb/working-with-contracts/contract-deferrals.md) have been created by a contract invoice, they will automatically be fully released on the **Posting Date of Credit Memo** when the contract invoice is credited. ## Delete unposted invoices As long as the invoice is not posted, it can be easily deleted. The billing lines are still in **Recurring Billing** and can be edited, updated or deleted there. The ability to edit unposted contract invoices or Credit Memos (**[posting documents](/docs/srb/posting-documents.md)**) is severely limited to avoid discrepancy between contract and posting documents. The same applies to the processing of billing lines and contract lines if there is a posting document. If the posting document has been deleted, the billing and contract lines can be edited normally. After editing a contract line, the billing line must be updated before a new posting document is created [Update Recurring Billing](/docs/srb/recurring-billing.md#need-to-update). ## Credit Memos for contract invoices Once the invoice is posted, it must be credited in order to make changes. The Credit Memo can be created in the posted invoice using the **Create Corrective Credit Memo** function. A Credit Memo and corresponding billing lines will be created automatically for the entire invoice. :::warning Attention The Credit Memo cannot be created if there are already new billing lines for the same contract line. The billing lines must be deleted in **Recurring Billing** before the Credit Memo can be created. Only the *last* contract invoice can be credited. If a subsequent bill has already been created for a contract, it must be credited first. ::: The Credit Memo is opened on creation. In the Credit Memo, positions can be deleted. In this way, individual positions of an invoice can be credited. When the positions are deleted, the billing lines are also deleted. The same applies if the entire Credit Memo is deleted. A new billing line cannot be created for a contract line if a posting document already exists for it. The posting document must be deleted or posted first. :::info If the billing lines for the Credit Memo do not appear in the Billing Proposal, the page may need to be manually refreshed (**Refresh**) or the Billing Template changed. ::: In the contract lines, the **Next Billing Date** was immediately reset when the Credit Memo was created. After posting the Credit Memo, the contract lines can be edited and calculated with the new values. --- ## Currencies # Dealing with currencies # Currencies In Business Central, transactions can be performed taking into account a foreign currency. The currency code is entered in the respective transaction. This can be done, for example, in the Sales Order or in the Customer/Vendor Contract. For more details on handling currencies, please refer to this part of the Microsoft documentation. ## Foreign Currency in Service Commitments If a currency code is entered, e.g. in a sales order (or this is stored at the customer), a corresponding conversion of the prices into the currency of the customer takes place. This is done in the same way for **Sales Service Commitments**. In the Service Commitments for the Service Object, the **Currency Code** field also indicates the currency to which the **Service Amount** refers. When manually creating a Service Object with Service Commitments, the **Currency Code** and the corresponding fields in the Service initially remain empty, even if a currency code has been defined in the Customer. The currency code can remain blank because the contract that the service is billed via later *decides* which currency will be used. When the Service Object and Service Commitments are created via Sales Shipment, the currency code from the Sales Order is automatically transferred to the Service. ## Convert Service Amounts When assigning Service Commitments to a contract, the system checks if the amounts need to be converted. If the currency code in the contract is the same as the currency code in the Service Commitments, no conversion is required. Otherwise the conversion is done by a query in which the last conversion factor is suggested to the user (based on the work date). Clicking *OK* will recalculate the fields relevant to the currency, update the Service Commitment and then add it to the contract. When changing the currency code in the contract, the dialog is also displayed. :::note Same currency code When assigning Service Commitments to a contract for which a conversion of the amounts are to be made, the same currency code must be stored in all selected services. ::: ## Update exchange rates on Service Object The method described here ensures that the agreed price for Service Commitments in a foreign currency does not automatically change as a result of a change in the exchange rate. However, it may be necessary to adjust the exchange rate manually. The action **Update exchange rates** can be used for this purpose. It is available in the Service Object as well as in the Customer and Vendor Contracts (under *Process*). :::info Manual price change A manual change by the user to one of the fields * Calculation Base Amount * Calculation Base % * Price * Discount % * Discount Amount * Service Amount leads to a corresponding update of the fields * Price (LCY) * Discount Amount (LCY) * Service Amount (LCY) based on the stored exchange rate. ::: ## Update exchange rates for currencies automatically In Business Central, it is possible to automatically update exchange rates using **[Job Queue](/docs/srb/setup/job-queue.md)**. For more details, please see this and this Microsoft documentation. --- ## Sales Price Calculation # Price determination of Service Commitments The price of a Service Commitment is automatically determined based on [Setup](/docs/srb/masterdata/service-commitments.md). Editing **Calculation Base Amount** and **Calculation Base %** is possible to change the price manually. * **Calculation Base Amount**. * **Item Price** The **Calculation Base Amount** of the Service Commitments is determined from the master data (Item card). For customer-side Service Commitments the **Unit Price** and for vendor-side Service Commitments the field **Last Direct Cost** is used. Changes to the sales price and cost price in the sales document have no effect. * **Document Price** The **Calculation Base Amount** is determined from the **Unit Price** for Customer Service Commitments and from the **Unit Cost** of the sales document line for Vendor Service Commitments. A change to the prices in the document line is automatically applied to all Service Commitments for the sales item. * **Document Price And Discount** The **Calculation Base Amount** is determined in the same way as the Document Price Type (see above). In addition, a discount entered in the sales item for the Service Commitments is transferred and taken into account when determining the Service Amount. This option is not available for vendor-side Service Commitments. * **Calculation Base Amount** * Calculation Base Amount is the basis for calculating the Service Amount. When selling a good with an additional recurring Service Commitment, the Calculation Base Amount is equal to the value of the good. * **Calculation Base %** * Calculation Base Amount % is the percentage from the **Calculation Base Amount** which is used to determine the price of the Service Commitment. * **Price** * The price is calculated from the **Calculation Base Amount** and the **Calculation Base %** * The price is always valid for the entire **Calculation Base Amount**. I.e. it is an annual price if a year (or 12 months) is entered in **Calculation Base Amount** and a monthly price if a month is entered in **Calculation Base Period**. --- ## Sales-related Procurement(Sales) # Procurement in connection with a Sales Order In Business Central, there are several ways to create Purchase Orders for retail items. The most common are the Requisition Worksheets (from the manufactoring module) and the functionality to create a Purchase Order from a Sales Order. However, if retail items are needed explicitly for a specific Sales Order, these two options fall short. In both cases, the goods are not ordered on an order-by-order basis. Thus, the reservation of the required quantity in the Sales Order line must be done manually. Especially in the second case, both the order (here: Sales Order line) lacks the link to the Purchase Order (here: Purchase Order line) expected by the user and vice versa. ## Create Purchase Order For this requirement, the separately available app **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** offers a simplification compared to the standard of Business Central. Further explanations on how to create Sales Order-related Purchase orders can be found in [this](/docs/ibt/sales-related-procurement.md) part of the DYCE documentation. :::note Unit costs for Service Commitment Items Since Service Commitment Items are always considered as a *service per period* and therefore also the Purchase and Sales prices are related to it, Service Commitment Items are initially transferred to the Purchase Order without Unit Cost. The Unit Cost can be changed in the **Create and connect Purchase Orders** page as well as in the created Purchase Order line. ::: ## Reservations For inventory items (**Type**=*Inventory*), the expected goods are automatically reserved for the Sales Order line when the Purchase Order is created. This is visible in the **Reserved Quantity** field in both the Sales Order line and the Purchase Order line. Clicking on the field will open the Reservation Entries. Reservations cannot be created for non-inventory items (**Type**=*Non-Inventory*). In this case, the standard functionality of Business Central is triggered and used to create Purchase Orders. --- ## Sales with Service Commitments # Sales process Create a Sales Quote or Sales Order (hereafter *Sales Document*) with Service Commitments to record your monetary agreements with the customer. Service Commitments are printed on the documents and can be delivered from the order to be billed on a recurring basis. ## Assign Service Commitments [Service Commitments](/docs/srb/masterdata/service-commitments.md) describe the monetary content of agreements with customers and vendors, as well as termination dates. If an item is used in a sales document that has one or more Service Commitments Packages defined in the master data, the services from the Service Commitments marked as **Standard**=*YES* are automatically created for the sales transaction. All Service Commitments from the corresponding Service Commitment Packages are transferred to the sales item in the document. The Service Commitments can then be accessed and viewed or edited via the lookup in the **Services** field in the sales document line ([see below](#view-edit-and-delete-service-commitments)). All Service Commitments not marked as **Standard**=*YES* can be assigned in the **Assign Service Commitments** selection window. The window opens automatically when an item is entered in the sales document if an optional Service Commitment Package (**Standard**=*NO*) is stored on the item. Since Standard Service Commitment Packages are always accepted, only optional Service Commitment Packages are displayed. If the selection window is opened using the **Add Service Commitment** line function, all available Service Commitment Packages for the item in the current sales item are displayed. By selecting the Service Commitment Package and confirming with *OK*, the Service Commitments of the Service Commitment Package are transferred to the selected sales item. It is not possible to select individual parts of a Service Commitment Package (Service Commitment Package Lines). The price calculation of the Sales Service Commitments is described [here](/docs/srb/sales/price-calculation.md). :::info Service Commitments in Sales Documents Service Commitments can be used in Sales Quotes, Sales Orders and Blanket Sales Orders. ::: ## Print Service Commitments Customer Service Commitments are automatically printed below the respective sales item. For each Service Commitments the description, the discount % and the sales price will be printed. The formatting from the corresponding sales item regarding **Print Line** is taken into account (as the only formatting) when printing Service Commitments. The amounts of Service Commitments and Service Commitment Items are not taken into account when calculating the line and total amounts. The total amounts of Service Commitments are calculated depending on the billing rhythm and are printed cumulatively below the sales items. For each billing rhythm used in the sales document, the recurring total amount is output (if it is greater than 0). The output of the total amounts is sorted by the duration of the billing rhythm. The total of the Sales Service Commitment, which have been created for a **Contract Renewal** is printed separately and labeled [Contract Renewal](/docs/srb/working-with-contracts/contract-renewal.md). ## View, Edit and Delete Service Commitments Whether Service Commitments have been entered for the sales item can be seen in the **Service Commitments** field in the respective sales document line. By clicking on the field, the Service Commitments can be viewed, edited and deleted. ## Shipping Service Commitments When an order item is shipped, a **Service Object** is automatically created if the delivered item is marked as **Service Commitment Option**=*Sales with Service Commitments* or **Service Commitment Option**=*Service Commitment Item* ([Item Master data](/docs/srb/masterdata/items.md)). The Sales Service Commitments belonging to the sales item are automatically transferred as Service Commitments. A new **Service Object** is created for each shipment. Delivered *Service Commitment Items* are automatically displayed as invoiced, because respective Service Commitments are invoiced exclusively via contracts. :::warning Important for auditors In Sales Orders, the behavior of Service Commitment Items differs significantly from that of *normal* items from the Business Central Standard. During an audit, the differences should be noted and explained to the auditor. If Service Commitment Items have been shipped in a Sales Order, they are automatically displayed as being invoiced. By clicking on the **Invoiced Quantity**, the lookup will not find a Posted Sales Invoice. No Sales Invoice is created when Service Commitments Items are shipped in order to avoid invoices with amount equals to 0 and to be able to deleted the Sales Order. Service Commitment Items are also displayed as invoiced in Posted Sales Shipments, although there is no corresponding Posted Sales Invoice and both the Item and Value Ledger entry show the **Quantity invoiced** to be 0. The Item and Value Ledger entries for the Service Commitment Items from Sales Orders are created with **Sale Amount** and **Cost Amount** equal to 0. The Item and Value Ledger entries for the Service Commitment Items from Sales Orders are created without an **Invoiced Quantity**. When invoiced by contract, the Item and Value Ledger entries are created with the **Invoiced Quantity** and **Sales Amount**. ::: The item and its description, as well as the customer and the delivery address are transferred to the **Service Object**. The quantity in the **Service Object** corresponds to the quantity in the shipment. All values from the Service Commitments in the order are transferred to the Service Commitments in the **Service Object**. The **Shipment Date** corresponds to the **Provision Start Date** in the **Service Object**. A **Agreed Serv. Comm. Start Date** can be entered in the Sales Service Commitment for a sales item. If a **Agreed Serv. Comm. Start Date** is maintained in the Sales Service Commitment, it will be used as the **Service Start Date** and **Next Billing Date** in the Service. If the field is blank, the **Service Start Date** and **Next Billing Date** will be determined from the Shipment Date and **Service Commitment Start Formula** (field only shown in the Service Commitment Package Line). Example: If delivery is on the 15th of a month and the **Service Commitment Start Formula** defines the first of the following month as the Service Start Date, the first of the following month is used. If the **Service Commitment Start Formula** is empty, the delivery date is used. :::tip Tip -CM+1M calculates the first day of the following month (see Date and Time Specifications documentation from Microsoft). ::: Based on the **Service Start Date**, the **Cancellation Period** fields are calculated. The **Cancellation possible until** specifies the date on which a Service Commitments can be cancelled in due time. It corresponds to the **Service Start Date** plus the **Initial Term** minus the **Notice Period**. The **Term until** indicates the next potential end date of a Service Commitments upon regular termination. It is equal to the **Service Start Date** plus the **Notice Period**. If an **Initial Term** is maintained, it corresponds to the **Service Start Date** plus the **Initial Term**. :::warning Attention The Service Commitment is not automatically terminated when the **Term until** is reached. If there is an agreed end of Service Commitment, the **Initial Term** must be maintained and the **Subsequent Term** must be empty. This way, upon delivery, the **Service End Date** is automatically determined based on the **Service Start Date**. ::: For more information on **Service Object** and Service Commitments, see [Managing Contracts and Services](/docs/srb/working-with-contracts/contracts-services-mgmt.md). ## Bundle with Services Commitments Multiple quote and order lines can be combined into a [Bundle](/docs/ebs/bundles.md). A bundle is like a single product that consists of several components. For example, a bundle can be used to combine a transfer fee and the ancillary costs (maintenance) into one bundle product. ## Inventory Picks When an item is delivered via Inventory Pick, either the Posting Date or the Shipment Date is used to calculate the Service Start Date. The **Service Start Date for Inventory Pick** field in the **[Service & Contract Setup](/docs/srb/setup/general.md#inventory-picks)** page determines which of the two options comes into play. ## Calculate orders Service Commitments cannot be charged (not even once) via a sales order. Although the item is billed once via the sales order, the Service Commitments are not billed via the sales order, but recurringly via a contract. Service Commitment Items cannot be billed at all. Service Commitment Items can be rentals, support, etc. that are offered and sold. They are automatically set to invoiced on delivery. Invoicing is also done recurrently via a contract. ## Archive documents Depending on the setting in **Sales & Receivables Setup**, sales quotes are automatically archived when converted to a sales order or sales orders are automatically archived when deleted (fast tab *Archive*). Sales quotes and orders can also be archived manually using the **Archive Document** action. In doing so, the Sales Service Commitments belonging to the lines are also archived. --- ## Contrat Types # Contract Types The **Contract Types** page defines which different types of contracts exist. They are used to manage and organize Customer and Vendor Contracts and can be used as filters for this purpose - e.g. also for billing. Examples can be maintenance or support contracts, but also insurances or other types of recurring incoming and outgoing invoices. For each Contract Type, an appropriate description should be entered in addition to a unique code. The description is further used as an info line in the posting documents for the contracts. :::info Translations The action of the same name can be used to define translations for the Contract Type, specifying the corresponding language code. These will be taken into account when creating the [contract invoices](/docs/srb/posting-documents.md). ::: ## Harmonized Billing The **Harmonized Billing Customer Contracts** indicator controls whether the contract elements of related Customer Contracts are billed on a common due date. If it is set, the corresponding fields in the *Harmonized Billing* group in the **Shipping and Billing** fast tab of the Customer Contracts card are editable. If the field is reset, the fields on the affected Customer Contracts will also be reset and disabled upon request. For more details on how this works, please refer to the [Harmonization of Contract elements](/docs/srb/working-with-contracts/customer-contracts.md#harmonized-billing) part. ## Default Without Contract Deferrals This field can be used to predefine the default value for the corresponding field in the Contract Header. This simplifies contract creation and reduces handling errors. When the Contract Type is selected, the value is copied to the field in the contract. The value can be changed manually if necessary. --- ## General Setup ## Service Contract Setup The **Service Contract Setup** page is where settings and defaults for creating and managing Customer and Vendor Contracts (such as number series) are made. :::tip Item Template The **Item Templates** contain DYCE-specific fields so they can be easily predefined for new master data records. ::: ### Default Period Calculation Determines which **Period Calculation** option will initially be set in Service Commitment Package line. The two options **Align to Start of Month** and **Align to End of Month** are explained in more detail in [Period and price calculation](/docs/srb/working-with-contracts/period-calculation.md). By changing the default, the value can be updated in ***all existing*** Service Commitments, Sales Service Commitments and Service Commitment Package lines. To do this, the dialog must be answered with *YES*. If the existing records are not updated, the Period Calculation remains unchanged. Only the default value for creating new Service Commitment Package lines changes. ### Inventory Picks If a location requires a dedicated warehouse activity when picking items (**Require Pick**=*YES* in the Location Card, fast tab *Warehouse*), the item is subsequently delivered via commission. In order to handle the base date for the calculation of the service start differently, the reference date can be specified via **Service Start Date for Warehouse Picking**. It is used when the item is shipped from a commission or warehouse pick. For more information on warehouse and logistics functionalities, please refer to this part of the Microsoft documentation. ### Dimensions The **Autom. Insert Cust. Contr. Dimension Value** field controls whether the Customer Contract No. is automatically created as a new dimension value for each new customer contract. This is then automatically assigned to the respective contract. Dimensions are usually used for evaluation purposes. For details on how dimensions work, please refer to this part of the Microsoft documentation. The default value for this setting is *YES*. ### No. Series The Number Series for Customer Contracts, Vendor Contracts, and Service Objects determine which principle is used to assign new numbers. The number series to be used when creating new entries are stored here. ### Invoice Details The selection in the **Origin Name for collective Sales Invoice** field controls which customer information is transferred to *collective invoices*. You can select the contractor (*Sell-to Customer*), the delivery recipient (*Ship-to Address*) or both. In this way, it is possible to control which customer information of the respective contracts is transferred to the collective invoices for several contracts. This is interesting for example in the partner business, if the end customer of the partner is deposited as the delivery recipient in the contract. The partner as the recipient of the invoice can thus easily understand which invoice components refer to which end customer. The field described here is a default that is translated to the **Contractor Name in collective Invoice** and **Recipient Name in collective Invoice** fields (*Invoice Details* fast tab in [Customer Contract](/srb/working-with-contracts/customer-contracts.md#details-for-contract-invoices)) when a new Customer Contract is created. The fields can be changed there. Decisive for the creation of the invoice are the fields of the respective Customer Contract. Whether additional texts, which are created during invoice creation for the contract lines and which description should be used in the invoice line, can be defined in the **Service Contract Setup** page in the **Invoice Details** tab. The **Description** field represents the description of the invoice line. The **Additional Lines 1 to 5** are created as text lines below the respective invoice line, depending on the configuration. The following contents can be passed to the invoice: * Description of the Service Object. * Description of the Service Commitments * Customer reference * Serial number * Billing period :::warning Billing period At least one of the additional lines must be set up to output the *billing period* to prevent this information from being missing in the invoice. If none of the additional lines is set up to output the billing period, the creation of the posting documents will abort with an appropriate error message. ::: ## Sales & Receivables Setup Explanations about the field **Autom. Insert Project Dimension Value** can be found in [this](/docs/general/essentials/customer-dimension.md) part of the DYCE documentation. ### Bundles For details on Bundle settings and defaults, please refer to [this](/docs/ebs/setup.md) part of the DYCE documentation. ### Document Sending Profiles Via **[Batch Sending Documents](/docs/general/essentials/batch-sending-documents.md)** it is controlled whether the settings defined at the customer are used for batch sending of posted documents or whether the standard dialog is displayed. For the default setting *Use customer's setup* no dialog is displayed. ## General Posting Setup The default G/L accounts to be used are set up in the same way as the Business Central standard via the General Posting Setup page. The fields **Customer Contract Account**, **Customer Contract Deferral Account**, **Vendor Contract Account** and **Vendor Contract Deferral Account** are available for revenues from Customer Contracts, costs from Vendor Contracts and their respective deferrals. The fields are also included in the related **General Posting Setup Card** page. For more details on how Contract Deferrals work and are handled, please see [here](/docs/srb/working-with-contracts/contract-deferrals.md). ## Reports Along with **DYCE Subscription & Recurring Billing**, the **DYCE Essentials** app is installed. The app includes, among others, enhancements to the dataset of the following standard reports: * **Purchase** * Purchase Order * Blanket Purchase Order * **Sales** * Quote * Order Confirmation * Blanket Sales Order * Shipment * Invoice (incl. details of Service Commitments invoiced) * Credit Memo * Reminder Furthermore, an additional DYCE layout for WORD and for RDL is supplied for each report. --- ## Data migration # Import of Contracts and Contract lines Before Contracts and Contract lines can be set up, some data must first be created or imported. In addition to Customers, Vendors, and Items, you need to create Service Commitment Packages, Service Commitment Package lines, and more. The import is done via configuration packages. The Customer Contracts, Contract lines, Service Objects and Service Commitments are imported into tables created specifically for processing the data. ## Import of master data For importing Customers, Items, Service Commitments, Vendor Contracts etc., [Configuration Packages](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/set-up-standard-company-configuration-packages) can be created. |Name|Table| |:--|:--| |Items|27| |Service Commitment Templates|70920754| |Service Commitment Packages|70920755| |Service Commitment Package Lines|70920756| |Item Service Commitment Packages|70920758| |Vendor Contract|70920763| ## Import of Customer Contracts, Contract lines, Service Objects and Service Commitments There are particular import tables for importing Customer Contracts, Contract lines, Service Objects and Service Commitments. After the import, the user can view, edit and use the data to create corresponding records in Business Central in the pages **Imported Customer Contracts**, **Imported Service Objects** and **Imported Service Commitments**. Please use the following tables to import and create Service Objects, Service Commitments and Contract lines. |Name|Table| |:--|:--| |Imported Customer Contracts|70920710| |Imported Service Objects|70920708| |Imported Service Commitments|70920709| ### Imported Customer Contracts The **Imported Customer Contracts** page serves as an intermediate step for the data transfer of Service Objects. The imported data is displayed in this page. The **Create Customer Contracts** action is used to create the Customer Contracts (just headers, no lines). The action always processes all rows that have not yet been processed, regardless of filters and selection. |Name|Description|To fill| |:--|:--|:--| |Contract No. (Code20)|Specifies the number of the contracts to be created. The Contract lines (Service Commitments) are assigned by means of the Contract No. Note: Before processing, the number series must be set to allow manual number assignment.|**Always**| |Sell-to Customer No. (Code20)|Indicates the number of the customer who receives the contractual services and is invoiced by default.|**Always**| |Sell-to Contact No. (Code20)|Specifies the number of the contact that receives the contractual services. In the contract, it is filled by the Sell-to Customer No. from that customer if empty.|Optional| |Bill-to Contact No. (Code20)|Indicates the customer to whom you send the Contract invoice. If empty the *Standard (Customer)* will be used in the contract.|Optional| |Contract Type (Code10)|Indicates the classification of the contract.|Optional| |Description (Text200)|Indicates the internal description of the contract.|Optional| |Your Reference (Text35)|Indicates the reference of the customer. The content of this field will be printed on the Contract invoice.|Optional| |Salesperson Code (Code20)|Indicates the name of the salesperson assigned to the customer.|Optional| |Assigned User ID (Code50)|Indicates the ID of the user who is responsible for the document.|Optional| |Without Contract Deferrals (Boolean)|Specifies whether deferrals should be generated for the contract. If the field is checked (yes), no deferrals will be generated and the invoices will be posted directly to profit or loss. Default value is *NO*.|Optional| |Detail Overview (Boolean)|Determines whether the billing details for this contract are automatically output with invoices and credit memos. Options: empty (default), Without prices, Complete|Optional| |Dimensions from Project No. (Code20)| Specifies the Project No. from which the dimensions for the contract are to be used.|Optional| If the processing is successful, a Customer Contract is created and **Contract Created** is set to *YES*. In **Processed by**, the user who performed the processing is automatically entered. In **Processed on**, the date and time of the processing are shown. Errors are displayed in the **Error Text** field. ### Imported Service Objects The **Imported Service Objects** page serves as an intermediate step for the data transfer of Service Objects. The imported data is displayed in this page. The **Create Service Objects** action is used to create the Service Objects. The action will always process all lines that have not yet been processed, regardless of filters and selection. |Name|Description|To be filled| |:--|:--|:--| |Entry No. (Integer)|System field of the table (consecutive number of records) - is created automatically and is in the background|*Never*| |Service Object No. (Code20)|The Service Object is created with this number. To facilitate the assignment of Service Commitments, this number should always be imported. Note: Before processing, the number series must be set to allow manual number assignment.|**Always**|. |Customer No. (Code20)|Indicates the number of the customer to whom the Service Commitments were sold. It is mandatory for the assignment to Customer Contracts.|**Always**| |Item No. (Code20)|Indicates the Item No. of the Service Object. It should be an item with Service Commitments or a Service Commitment Item.|**Always**| |Description (Text100)|Indicates the description of the Service Object. If the description is empty, it will be filled by the item when the Service Object is created.|Optional| |Quantity (Decimal)|Indicates the quantity of the Service Object.|**Always**| |Customer Reference (Text35)|Indicates the reference by which the customer knows the Service Object.|Optional| |Bill-to Cust. No. (Code20)|A different invoice recipient (Customer) can be specified here. Related fields will be filled automatically (e.g. Bill-to Contact No. etc.).|Optional| |Bill-to Contact No. (Code20)|A different invoice recipient (Contact) can be specified here.|Optional| |Ship-to Code (Code10)|A different shipment address can be specified here. Related fields will be filled automatically.|Optional| |Contact No. (Code20)|Can be specified if different from primary contact.|Optional| |Unit of measure (Code10)|Can be specified if different from the unit of the item.|Optional| |Serial No. (Code50)|Indicates the serial number of the Service Object. Service Objects with serial number can only have a **Quantity**=*1*.|Optional| |Provision Start Date (Date)|Indicates the date from which the Service Object and the related Service Commitments were provided to the customer. It has no relevance for billing.|Optional| |Provision End Date (Date)|Indicates the date from which the Service Object and related Service Commitments are no longer available to the customer. It has no relevance for billing.|Optional| |Key (Text100)|Displays a key in the Service Object.|Optional| |Version (Text100)|Display of the version in the Service Object.|Optional| If the processing is successful, a Service Object is created and **Service Object Created** is set to *YES*. In **Processed by**, the user who performed the processing is automatically entered. In **Processed on**, the date and time of the processing are shown. Errors are displayed in the **Error** field. ### Imported Service Commitments The **Imported Services Commitments** page serves as an intermediate step for the data transfer of Service Commitments and Contract lines. The data is imported into this page and processed using the **Create Service Commitments** action. This can be used to create comment lines in Contracts, Service Commitments that are not billed, as well as Contract lines and Service Commitments that are billed. The action will always process all lines that have not yet been processed, regardless of filters and selection. |Name|Description|To be filled| |:--|:--|:--| |Entry No. (Integer)|System field of the table (consecutive number of records) - is created automatically and is in the background|*Never*| |Service Object No. (Code20)|The created Service Commitment will be assigned to this Service Object.|**Always**| |Service Commitment Line No. (Integer)|Indicates the line number of the service in the Service Object. If no line number is specified, one will be determined automatically.|Optional| |Partner (Option: Customer, Vendor)|Indicates if the Service Commitments should be invoiced vendor-side (Purchase Invoice) or customer-side (Sales Invoice).|**Always**| |Contract (Code20)|Indicates the number of the contract in which the Service Commitment is to be created as a Contract line. Service Commitments with **Invoicing via**=*Sales* cannot be called up in Contracts.|Optional| |Contract Line No. (Integer)|Indicates the line number of the Contract line. If no line number is specified, one will be determined automatically.|Optional| |Contract Line Type (Option: Comment, Service Commitment)|Specifies the type of the Contract line.|**Always**| |Package Code (Code20)|Specifies the code of the Service Commitment Package. If a Vendor Contract line has the same Service Object and Package code as the Customer Contract line, the Customer Contract dimension will be copied to the Vendor Contract line.|Optional| |Template Code (Code20)|Indicates the name of the underlying Service Commitment Template from which the Service Commitment was copied to the Service Commitment Package. It has a purely informative character.|Optional| |Description (Text100)|Indicates the description of the Service Commitments. If no description is specified, it will be filled based on the Service Commitments.|**Always**|. |Service Start Date (Date)|Indicates from which date the Service Commitments is valid and will be charged.|**Always**| |Service End Date (Date)|Indicates until which date the Service Commitments is valid.|Optional| |Next Billing Date (Date)|Indicates the date of the next possible billing. If the field is empty, it will be filled automatically by the Service Start Date.|Optional| |Calculation Base Amount (Decimal)|Indicates the base amount from which the price will be calculated. *Note: The field **Price** (in Service Commitments) is always calculated and* never *imported*.|**Always**| |Calculation Base % (Decimal)|Indicates with which percentage the Service Commitment price is calculated. 100 % means that the price of the Service Commitment is equal to the Calculation Base Amount.|**Always**| |Discount % (Decimal)|Indicates the percentage discount for the Service Commitments.|Optional| |Discount Amount (Decimal)|Indicates the discount amount that will be applied to the Service Commitments. Only Discount % or Discount Amount must be filled for the import to apply a discount.|Optional| |Service Amount (Decimal)|Indicates the amount minus the discount granted. The Service Amount is calculated from Calculation Base Amount, Calculation Base %, Quantity, and Discount if the field is not filled.|Optional| |Calculation Base Period (Dateformula)|Indicates the period to which the Service Amount refers. For 1M the amount refers to one month or 12M if the amount refers to 1 year.|**Always**| |Invoicing via (Option: Sales, Contract)|Indicates whether the Service Commitment is invoiced via a Contract. Service Commitments with **Invoicing via**=*Sales* are not invoiced and cannot be transferred to a Contract.|**Always**| |Invoicing Item No. (Code20)|Indicates which item is used in the Contract invoice for invoicing the periodic Service Commitments. It must be an item with the **Service Commitment Option**=*Invoicing Item*.|Optional| |Notice Period (Dateformula)|Specifies a Dateformula for the lead time that a cancellation must have before the Service Commitment is terminated. The Subsequent Term is also used to determine the rate at which **Cancellation Possible Until** and **Term Until** are updated. Thus, for a Subsequent Term of 1M, the notice period is recurrently postponed by one month.|Optional| |Initial Term (Dateformula)|Specifies a Dateformula for calculating the minimum term of the Service Commitment. If the Initial Term is filled and no Subsequent Term is entered, the Service End Date is automatically set to the end of the Initial Term.|Optional| |Subsequent Term (Dateformula)|Specifies a Dateformula for automatic extension after the Initial Term and the rhythm of updating **Cancellation Possible Until** and **Term Until**. If the field is blank and either the Initial Term or the Notice Period is set at the same time, the Service End Date is automatically set to the expiration date of the Initial Term or the Notice Period.|**Always**|. |Billing Rhythm (Dateformula)|Specifies the rhythm at which the Service Commitments will be billed. Via a Dateformula the rhythm can be set to e.g. monthly, quarterly or yearly calculation.|**Always**| |Print Line (Boolean)|Specifies whether a line is output when the sales document is printed.|Optional| |Formatting (Option: Normal, Bold, Italic)|Specifies whether a line in the sales document is printed bold or italic (default: *Normal*).|Optional| |Print Discount % (Boolean)|Specifies whether the line discount percentage is printed for the line in the sales document (default: *YES*).|Optional| |New Page (Boolean)|Specifies whether a new page should be started with this line in the sales document (default: *NO*).|Optional| |Print Quantity only (Boolean)|Specifies that only the quantity (without sales price) is printed for the corresponding line in the sales document (default: *NO*).|Optional| *Mandatory fields (always) apply to the creation of billable Contract lines. Mandatory fields e.g. for comment lines differ. If the processing is successful, Service Commitments and Contract lines are created and **Service Object created** is set to *YES*. In **Processed by**, the user who performed the processing is automatically entered. In **Processed on**, the date and time of processing are shown. Errors are displayed in the **Error** field. :::tip Tip To create a comments line in a contract, the **Contract No.**, **Description** and **Invoicing via**=*Contract* must be entered. ::: The following fields only need to be considered if a currency different from the local currency is used. The currency is defined by the contract. To avoid the conversion at a different rate, currencies can be imported. |Name|Description|To be filled| |:--|:--|:--| |Discount Amount (MW) (Decimal)|Indicates the discount amount in local currency that will be applied to the Service Commitments.|Optional| |Service Amount (MW) (Decimal)|Indicates the amount minus the discount granted in local currency. In the Contract, the Service Amount and not the Service Amount (MW) in is used for invoicing.|Optional| |Currency Code (Code10)|Indicates the currency for the Service Commitments.|Optional| |Currency Factor (Decimal)|Indicates the currency factor valid for the Service Commitments, which is used to convert the amounts into local currency.|Optional| |Date Currency Factor (Date)|Indicates the date when the currency factor was last updated.|Optional| |Calculation Base Amount (MW) (Decimal)|Indicates the basis on which the price in local currency is calculated.|Optional| The following fields only need to be considered if billing is to take place with **[DYCE Usage Based Billing](/docs/ubb/welcome.md)**: |Name|Description|To be filled| |:--|:--|:--| |Usage Based Billing (Boolean)|Indicates whether usage data is used as the basis for invoicing.|Optional| |Usage Based Pricing (Option: Usage Quantity, Fixed Quantity, Unit Cost Surcharge, Consumed Quantity)|Specifies the method for calculating prices on the Customer side.|Optional| |Pricing Unit Cost Surcharge % (Decimal)|Specifies the surcharge in percent for the Customer price calculation, if Unit Cost Surcharge is to be used.|Optional| |Supplier Reference Entry No. (Integer)|Indicates the sequence number of the related reference.|Optional| --- ## Job Queue For recurring tasks, in Business Central the Job Queue is used. For details on how the Job Queue works and how to configure it, please refer to this part of the Microsoft documentation. When **DYCE Subscription & Recurring Billing** is installed, the following entries are automatically created in the Job Queue: * **Update Service Dates** (codeunit 70920758) This task is used to automatically update the date fields in Service Commitments. Please refer to [this](/docs/srb/working-with-contracts/service-commitment-cancellation.md) documentation for the details of this functionality. The task is executed daily at 1am. --- ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. ## DYCE Subscription & Recurring Billing The following three permission sets are included with the app: * **DYCECONTRACTSALL (DYCE SRB Read)** This permission set can be assigned to all users. It contains read-only permissions to app-specific data. * **DYCECONTRACTSUSER (DYCE SRB Edit)** This permission set is for all users working with Service Commitments, [Service Objects](/docs/srb/working-with-contracts/service-objects.md) and Contracts. In addition, Billing Proposals can be created for contracts via [Recurring Billing](/docs/srb/recurring-billing.md) page. However, setting up, creating, and editing [Service Commitment Templates](/docs/srb/masterdata/service-commitments.md#service-commitment-templates) and [Service Commitment Packages](/docs/srb/masterdata/service-commitments.md#service-commitment-packages) is not intended with these permissions. * **DYCECONTRACTSADMIN (DYCE SRB Admin)** This permission set is designed for administrators and power users who should additionally be able to create and delete [Service Commitment Templates](/docs/srb/masterdata/service-commitments.md#service-commitment-templates) and [Service Commitment Packages](/docs/srb/masterdata/service-commitments.md#service-commitment-packages) and customize [Setup](/docs/srb/setup/general.md). The permission sets build on each other and contain the respective underlying set. For more information about permission sets, see this part of the Microsoft documentation. ## More DYCE Apps Along with **DYCE Subscription & Recurring Billing**, the apps **[DYCE Essentials](/docs/general/essentials/welcome.md)** and **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** are installed. This will provide cross-app functionality such as [Bundles](/docs/ebs/bundles.md), a [Print Preview](/docs/general/essentials/print-preview.md) or the [Report Configurations](/docs/general/essentials/report-configuration.md). Three permission sets are included with the app: * **DYCEESSENTIALSALL (DYCE Essentials All)** This permission set can be assigned to all users. It includes read-only permissions to app-specific data. * **DYCEESSENTIALSUSER (DYCE Essentials Users)** This permission set is for all users working with [Bundles](/docs/srb/bundles.md). * **DYCEESSENTIALSADMIN (DYCE Essentials Admin)** This permission set is designed for Administrators and Power Users who should additionally be able to create, customize and delete [Report Configurations](/docs/general/essentials/report-configuration.md). --- ## Data migration(Srb) # From DYCE Subscription & Recurring Billing to Microsoft Subscription Billing To switch from **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing** to Microsoft **Subscription Billing**, a migration routine is available for data migration. This is included in **DYCE Subscription & Recurring Billing** from version 2025.7. The execution of the data migration routine is subject to a charge (in the form of password protection) and must be purchased from **Singhammer IT Consulting AG** (further details [see below](#process)). ## Prerequisites {#prerequisites} Business Central 2025 release wave 1, Update 3 (BC26.3) and later provide the necessary prerequisites for [data migration](#process) and [compatibility](#compatibility) of other **DYCE** apps with Microsoft **Subscription Billing**. In addition to updating to this or a newer version of Business Central, it is therefore also necessary to update all **DYCE** apps to at least version 2025.7. If there are also customizations in the form of per-tenant extensions (*PTEs*), compatibility with the corresponding versions of Business Central and the **DYCE** apps must also be established first. ### Checklist The following checklist can be used to plan the changeover optimally: * **Custom layouts (Word/Excel)** Example: Have quotes, order confirmations, invoices, credit memos or reminders been customized? * **Power Automate Flows or other workflows** Example: Are there automated email notifications for new contract lines? * **Interfaces to third-party systems** Example: Are there connections to a CRM, ticket or document management system? * **Number of companies to be migrated** Example: Do several companies or countries need to be migrated? * **Permissions that need to be adjusted manually?** Example: Are individual permissions to objects or user roles in use? * **Power BI or Excel reports that access SRB data** Example: Are there reports (e.g. on recurring sales) that currently still use data from **DYCE Subscription & Recurring Billing**? * **Internal documentation or terminology that should be adapted** Example: Are there user manuals, training documents or internal processes that refer to **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing**? If individual points apply, more time should be planned for the changeover in order to address these topics sufficiently and in good time. ## Notes * The **Subscription Billing** module in Business Central can now be extended in principle. However, as usual, not all areas are already accessible. Missing extension options may have to be requested directly from Microsoft in the usual way. * The migration routine for data migration can also be extended for customer customizations. * The routine transfers *all* data from **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing** to Microsoft **Subscription Billing**. The data in **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing** is then deleted. * The migration routine provides the required indirect permissions for the tables in which the users are not allowed to write directly. Compared to the standard user permissions (AUTOMATE - EXEC, D365 BACKUP/RESTORE, D365 BUS PREMIUM, D365 READ, EXCEL EXPORT ACTION, LOCAL, LOGIN, TROUBLESHOOT TOOLS), the following permission sets are also required to perform the data migration: * **DYCE SRB Admin** (DYCECONTRACTSADMIN) * **Subscription Billing Admin** (SUB. BILLING ADMIN) * **D365 Setup** * **SECURITY** * As an alternative to the permission sets mentioned here, the **SUPER** set can also be used. * Depending on the installed third-party apps, further permission sets may be necessary. * The execution of the migration routine is subject to a charge ([see below](#process)). ### Sunsetting **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing** * From **15.07.2025**: No more new feature requests, only bug fixes * From **31.12.2025**: No more new integration events and extensibility requests * As of **30.06.2026**: End of life for **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing** and the associated deactivation of the apps on AppSource * The changeover must therefore be completed by **30.06.2026**. ## Procedure {#process} If the above [prerequisites](#prerequisites) are met, the conversion from **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing** to Microsoft **Subscription Billing** can be carried out. :::warning Testing in a sandbox We recommend testing the implementation of the data migration, the compatibility of the **DYCE** apps used and, if necessary, the updated customer customizations in a sandbox before converting the production system. Business Central, **DYCE** apps and any customer customizations should therefore be updated in this environment first. ::: The routine for data migration is included in **DYCE Subscription & Recurring Billing** from version 2025.7. A password is required to run the routine. A password is valid for one calendar month. The passwords required to carry out the data migration can be obtained from the **Singhammer IT Consulting AG** sales team. ### Carry out data migration 1. Make sure that you are using the role center **DYCE Subscription & Recurring Billing**. This step is optional, as the next step can also be started independently from the role center used. However, this role center makes it easier to call up the **Service & Contract Setup** page and displays the tiles with values for **DYCE Subscription & Recurring Billing** entities. 2. Open the **Service & Contract Setup**. 3. Call up the action **Run Data Migration to Microsoft Subscription Billing**. 4. To perform data migration, the next step is to enter the corresponding password. 5. Monitor the progress of the processing. Once processing is complete, the **Data migrated to Microsoft Subscription Billing** field in the *Data migration* fast tab is activated. 6. Repeat the data migration for all companies. Data migration can only be carried out once per company. 7. Then call up the action **Run Permission Sets Migration to Microsoft Subscription Billing**. However, this only makes sense if the standard permission sets for **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing** have been used by the users. Otherwise, add respective standard permission sets for Microsoft **Subscription Billing** manually or create custom ones. Once processing is complete, the **Permissions migrated to Microsoft Subscription Billing** field in the *Data migration* fast tab is activated. 8. Switch to the role center **Subscription Billing** to check the migrated data. 9. Check whether all permission sets have been migrated correctly. If the users use the standard permission sets for **DYCE Subscription & Recurring Billing** and **DYCE Usage Based Billing**, these users should have been assigned the standard permission sets from Microsoft **Subscription Billing**. 10. Verify that Microsoft **Subscription Billing** works as expected with the migrated data. For example, review the use of subscription packages, as well as the creation of new billing proposals and contract invoices. 11. If the app **DYCE Hide Subscription Billing by Microsoft** (per-tenant extension, PTE) is installed, it can be uninstalled after the data migration. ## Compatibility of other DYCE apps with Microsoft Subscription Billing {#compatibility} All **DYCE** apps are fully compatible with Microsoft **Subscription Billing**. The minimum requirement for Business Central is - depending on the app constellation - either Business Central 2025 Release Wave 1, Update 3 (BC26.3) or Update 4 (BC26.4). --- ## Contract Deferrals The system provides a control option that when an invoice is prebilled, the customer-side revenues and vendor-side costs from future months are not yet posted to revenue or expense in the month the invoice is created. In this case, the net invoice amount is not posted to a revenue or expense account, but to an accrual account. This deferrals will later be released to income on a monthly basis. ## Prerequisite and setup When posting a contract invoice, *Contract Deferrals* are automatically created if the **Without Contract Deferrals** indicator in the Contract Header is set to *NO*. Contract Deferrals are used for Deferred Income (Customer Contracts) or Prepaid Expenses (Vendor Contracts). ## Contract Deferrals Customer Contract Contract Deferrals from customer contracts are used for deferring revenues in sales invoices. The G/L accounts that are posted to are those that have been defined in the Posting Matrix Setup for each combination of Gen. Bus. Posting Group and Gen. Prod. Posting Group possible in a business transaction. In the Customer Contract, this is the combination of the Customer's Gen. Bus. Posting Group in the Contact Header and the Gen. Prod. Posting Group of the [Invoicing Item](/docs/srb/masterdata/items.md). By default, the account used per combination is the one stored in the **Customer Contract Deferral Account** field in the **General Posting Setup**. However, if the **Without Contract Deferrals** indicator is set to *YES* in the Customer Contract Header, the invoice amount is immediately posted as revenue to the account defined in the **Customer Contract Account** field. Contract Deferrals will not be created in this case. :::warning Contract Deferrals for Prepaid Services For contract lines connected to a Prepaid Service, *contract deferrals* are created on the customer contract but are excluded from the **Contract Deferrals Release** process. Revenue is posted from deferral to revenue accounts only through **Prepaid Service** *processing*, either by posting **Prepaid Service** related invoices (*consumption*) or by running **Expire Residuals** report. ::: ### Calling Contract Deferrals from Customer Contracts Customer Contract Deferrals can be accessed in the Customer Contract Card using the **Customer Contract Deferrals** action. The page that opens displays the following information in detail: * The **Posting Date** indicates per accrual for when it was created. For the first deferral (per document) the posting date of the document is used, for all further deferrals the first day of the respective month is used. * The **Contract No.** indicates the number of the contract for which the deferrals were created. * The **Document Type** indicates the Document Type used to create the deferrals. * The **Document No.** indicates the Document No. with which the deferral was generated. * The **Service Object Description** field contains the description of the associated Service Object that was Invoiced via the document line. * The **Service Commitment Description** field contains the description of the associated Service Commitment that was invoiced via the document line. * The **Bill-to Cust.-No.** is the number of the customer (invoice recipient) for which the deferrals were generated. * The **Customer No.** is the number of the Customer (Contractor) for whom the deferrals were generated. * The **Discount Amount** field contains the (pro-rata) discount amount of the deferrals. * The basis for the deferrals for a document is represented in the **Deferral Base Amount** field. * The **Discount %** field contains the percentage rate associated with the **Discount Amount**. * The amount per deferrals is displayed in the **Amount** field. * The **Released** field indicates whether the deferral has already been released. * The **Contract Type** field displays the contract type of the associated contract. * The **User ID** field displays the ID of the user who posted the document and thus created the deferrals. * The **Document Posting Date** field contains the Posting Date of the document that was used to create the accrual. * The **Release Posting Date** field contains the Posting Date on which the accrual was released. * **Number of Days** displays the days belonging to each deferral. * **General Ledger Entry No.** contains the number of the G/L item with which the deferral was released. * The **Entry No.** is assigned when the deferrals are created from the specified number series. :::tip Preview Posting The deferrals to be created can also already be checked in the unposted contract invoices via the **Preview Posting**. ::: ## Contract Deferrals Vendor Contracts Contract Deferrals from vendor contracts are used for deferring cost in purchase invoices. In the case of post-invoicing (i.e. the retroactive calculation of Service Commitments), on the other hand, postings are always made immediately with an immediate effect on costs. Since the period is already in the past, Contract Deferrals are not needed here and are not created. Analogous to the Customer Contract, the G/L accounts to be posted to are determined using the Posting General Posting Setup for the respective business transaction. In the Vendor Contract, this is the combination of the Vendor's Gen. Bus. Posting Group in the Contract Header and the Gen. Prod. Posting Group of the [Invoicing Item](/docs/srb/masterdata/items.md). By default, the account used is the one stored in the **Vendor Contract Deferral Account** field in the **General Posting Setup**. However, if the **Without Contract Deferrals** indicator is set to *YES* in the Vendor Contract Header, the invoice amount is immediately posted as a cost to the account stored in the **Vendor Contract Account** field. Contract Deferrals will not be created in this case. ### Calling Contract Deferrals from Vendor Contracts Vendor Contract Deferrals can be accessed in the Vendor Contract Card using the **Vendor Contract Deferrals** action. The page that opens is the same as the one for [Customer Contract Deferrals](#calling-contract-deferrals-from-customer-contracts). ## Methodology for creating Contract Deferrals When posting the contract invoice, Contract Deferrals are created using the following schema: * The total amount (**Deferral Base Amount** field) is divided among the number of deferrals to be created. * When the *first* deferral is created for the billing line, a check is made to see if the start of the billing period is the *first* day of a month. If not, the **Amount** is prorated to the day (using **Deferral Base Amount**) based on the *first* month. * When the *last* deferral is created for the billing line, a check is made to see if the end of the billing period is the *last* day of a month. If not, the **Amount** is prorated to the day (using **Deferral Base Amount**) based on the *last* month. * Line discounts are not included in the **Deferral Base Amount**. * Rounding differences are added to the *last* deferral created for the invoice line. ## Release deferrals The batch report **Contract Deferrals Release** is used to release invoice deferrals. This report runs through all contract deferrals (customer and vendor), filters using **Posting Until Date** from the report request page to the **Posting Date** and **Document Posting Date** fields, and reposts the items thus found from the accrual account to the cost or revenue account. The release takes place for debit-side and credit-side contract accruals at the same time. The **Posting Date** field from the report request page is used as the *Posting Date* for the closure. At the same time, the **Released** field in the Contract Deferrals is set to *YES*. It is therefore recommended to trigger the release of Contract Deferrals on a monthly basis (e.g. at the end of the month). :::tip Automatic release Contract Deferrals can also be released automatically via the [Job Queue](/docs/srb/setup/job-queue.md). To do this, the report 70920751 **Contract Deferrals Release** must be set up as an entry in the Job Queue. In this case, the workdate is used for the two fields **Posting Date** and **Posting Until Date**. ::: When posting the release, the Source Code will be used, which is stored in the **Contract Deferrals Release** field in the **Source Code Setup** page. :::warning Note * If deferrals have been created by a contract invoice, they will automatically be fully released on the **Posting Date of Credit Memo** when the contract invoice is credited. * Contract deferrals should not be released to **future periods**. * Credit memos should not be posted to **past (supposedly closed) periods**. The release and correction of the contract deferrals occur on the document date of the credit memo. This could distort the reporting and the advance VAT return already created. If the credit memo was posted in past periods, these two points, among others, must be corrected in coordination with the departments (internal financial accounting/tax advisor). ::: ## Dimensions and updates If a dimension is updated on a contract line for which deferrals exist, it makes sense to update the related deferrals as well, so that subsequent resolution postings use the same dimensions. For this purpose, the action **Update Dimensions in Deferrals** is available in the respective Customer or Vendor Contract card. It updates the dimensions in all Contract Deferrals not yet released for the respective contract. If there are no deferrals for a contract, the action is not available. After the action has been run, the user receives a corresponding message. ## Output of deferrals For the control of the deferrals and for the submit for auditors it is possible to export the deferrals to Excel or to print them. For this purpose, the calls **Customers Contract Deferrals Analysis** and **Vendors Contract Deferrals Analysis** (*Alt+Q*) can be used. ## Examples ### Example 1: 1 year, full months * Base amount for deferrals: 1,200.00 * Start date: 01.01.2021 * End date: 12/31/2021 * Basis monthly amount: 1,200.00 * Number of full months: 12 * Monthly amount: 100,00 Posting Date|Number of Days|Deferral Base Amount|Amount |--:|--:|--:|--: |01.01.2021|31|1.200,00|100,00 |01.02.2021|28|1.200,00|100,00 |01.03.2021|31|1.200,00|100,00 |01.04.2021|30|1.200,00|100,00 |01.05.2021|31|1.200,00|100,00 |01.06.2021|30|1.200,00|100,00 |01.07.2021|31|1.200,00|100,00 |01.08.2021|31|1.200,00|100,00 |01.09.2021|30|1.200,00|100,00 |01.10.2021|31|1.200,00|100,00 |01.11.2021|30|1.200,00|100,00 |01.12.2021|31|1.200,00|100,00 ### Example 2: 1 year with subperiods * Basis amount for deferrals: 1,200.00 * Start date: 01/15/2021 * End date: 01/14/2022 * Basis monthly amount: 1,098.08 * Number of full months: 11 * Monthly amount: 99.83 Posting Date|Number of Days|Deferral Base Amount|Amount |--:|--:|--:|--: |15.01.2021|17|1.200,00|55,89 |01.02.2021|28|1.200,00|99,83 |01.03.2021|31|1.200,00|99,83 |01.04.2021|30|1.200,00|99,83 |01.05.2021|31|1.200,00|99,83 |01.06.2021|30|1.200,00|99,83 |01.07.2021|31|1.200,00|99,83 |01.08.2021|31|1.200,00|99,83 |01.09.2021|30|1.200,00|99,83 |01.10.2021|31|1.200,00|99,83 |01.11.2021|30|1.200,00|99,83 |01.12.2021|31|1.200,00|99,83 |01.01.2022|14|1.200,00|45,98 ### Example 3: less than 1 year with subperiods * Basis amount for deferrals: 1,022.47 * Start date: 01/15/2021 * End date: 21.11.2021 * Basis monthly amount: 897.54 * Number of full months: 9 * Monthly amount: 99.73 Posting Date|Number of Days|Deferral Base Amount|Amount |--:|--:|--:|--: |15.01.2021|17|1.022,47|55,89 |01.02.2021|28|1.022,47|99,73 |01.03.2021|31|1.022,47|99,73 |01.04.2021|30|1.022,47|99,73 |01.05.2021|31|1.022,47|99,73 |01.06.2021|30|1.022,47|99,73 |01.07.2021|31|1.022,47|99,73 |01.08.2021|31|1.022,47|99,73 |01.09.2021|30|1.022,47|99,73 |01.10.2021|31|1.022,47|99,73 |01.11.2021|21|1.022,47|69,01 --- ## Contract Renewal Some Contract lines are set to end at a certain date. These Contract lines can be extended with a Contract Renewal Quote. By using the Contract Renewal, a renewal period can be specified and a Sales Quote created subsequently. The **Service End Date** (in the Service Commitment / Contract line) will be extended once the Sales Quote is turned into a Sales Order and shipped. ## Creating a Contract Renewal Quote A Contract Renewal Quote can be created on the **Contract Renewal** page and through the Customer Contracts. The **Contract Renewal** page can be used to create Contract Renewal Quotes for all Contract lines that are about to expire or have expired. Open the search (*Alt+Q*) and type *Contract Renewal* to open the page. The action **Get Contract Lines** will open a filter page. On this page it is possible to filter for Contract lines that need to be renewed. ### Get Contract Lines The action can be accessed in the **Contract Renewal** page and shows a filter page. On this filter page, set a date in the **Service End Date** field to specify the earliest **Service End Date** from which the Contract lines are to be considered. The **Add Vendor Contract Lines** field specifies whether to include the related vendor-side Contract lines. If so, the Service Objects of the relevant Vendor Contract lines are checked to see if any additional vendor-side Service Commitments exist. Any non-closed Vendor Service Commitments associated with a Vendor Contract that have a **Service End Date** will also be considered for Contract Renewals. Thus, if you set **Add Vendor Contract Lines** to *YES*, all vendor-side Service Commitments of the same Service Object will also be considered for renewal. If additional filters are needed, you can filter by any field in Customer Contract and Service Commitments. After confirming the filters entered, **Renewal lines** will be created for all valid Contract lines. A Contract line is *valid* if a **Service End Date** is set within the filter and the line is not closed, yet. All lines are displayed in the Contract Renewal page. :::info Closed Contract Lines Contract lines are closed when reaching the **Service End Date**. Closed Contract lines can be found in the fast tab **Closed Lines** in the Contract Card page. They can be reopened by changing **Closed** to *NO*. ::: In order to renew a Contract line, the **Renewal Term** has to have a value. It is prefilled from the **Initial Term** of the corresponding Contract line. The value can be changed to match the desired term of renewal. :::warning Preventing duplicates A Contract Renewal line can only be created if there is no line in a Sales Quote for renewal belonging to that Contract line. ::: ### Create Quotes Calling the action **Create Quotes** on the Contract Renewal page will create new Sales Quotes. The user can perform the action either for all lines or for selected lines only. All Contract Renewal lines for which Sales Quotes have been created will be deleted. If the **Renewal Term** field in the renewal line has no value, the renewal line will not be included in a quote and therefore will not be renewed. The created lines in the Sales Quote are of type *Service Object* and are marked as **Contract Renewal**=*YES*. The Sales Service Commitment can be changed and new items can be added in the Sales Quote. Adding new Service Commitments to the existing Sales lines (marked as **Contract Renewal**=*YES*) is not possible. Sales Quotes can be printed. The Sales lines marked as **Contract Renewal**=*YES* are set (via formatting) to print only the quantity, to avoid confusion between renewing the Service Commitments and selling additional items. The price of Sales Service Commitments is printed. The total of the Sales Service Commitment to be renewed is printed separately and labeled *Contract Renewal*. ## Sales Order In order to renew Contract lines, the Sales Quote has to be turned into a Sales Order and shipped (from the system's point of view). Sales lines marked as **Contract Renewal** can only be shipped in full or excluded from delivery. The *posting of shipment* serves as a standardized step to start processing. In this process, the line as such is not actually shipped, but only the Service Commitments for which the extension/renewal was offered is updated (see below). Therefore, there are neither posted shipments nor posted invoices for these renewals. Service Commitments are invoiced via the next Contract invoice. Nevertheless, shipments and invoices can be created for items that are not **Contract Renewals**. On shipping the Sales Order, the Contract lines are either renewed or a **Planned Service Commitment** will be created. The Contract line will be renewed and the **Service End Date** changed, if none of the following fields have been changed in the Sales Service Commitment: * Calculation Base Amount * Calculation Base % * Price * Discount % * Notice Period * Calculation Base Period * Billing Rhythm If one of these fields have been changed and the Contract line has not been invoiced up to the **Service End Date**, a **Planned Service Commitment** will be created. The **Planned Service Commitment** saves the changes to the Contract line and thereby ensures that the Contract line can be invoiced with current conditions until the **Service End Date**. If the Contract line is invoiced up to the **Service End Date**, the Contract line will be updated from associated **Planned Service Commitment**. The **Planned Service Commitment** is deleted after the update. :::info Planned Service Commitments **Planned Service Commitments** for specific Contract lines can be reviewed via the lookup in field **Planned Service Commitment exists** in the *Lines* fast tab of a Customer Contract card page. By searching for *Planned Service Commitments* (*Alt+Q*), the page of the same name shows all **Planned Service Commitments** for all contracts. Since **Planned Service Commitments** can also exist for Vendor Service Commitments, this field is also present in Vendor Contract lines. ::: ## Customer Contract The renewal of a *specific* Customer Contract can be achieved by calling the action **Create Contract Renewal Quote** in the menu group *Home* of the Customer Contract card page. Subsequently, the page **Select Contract Lines for Renewal** is opened. :::warning Existing Contract Renewal lines and Sales Quotes Calling the action **Create Contract Renewal Quote** will delete already created Contract Renewal lines. A new Sales Quote for a Contract line cannot be created if there is already a Sales Quote or Sales Order for that Contract line. ::: In page **Select Contract Lines for Renewal** only *valid* Contract lines will be displayed. A Contract line is valid if a **Service End Date** is set and the line is not closed, yet. In order to renew a Contract line, a value must be specified in **Renewal term**. This is predefined from the **Initial Term** of the corresponding Contract line. The value can be changed to achieve the desired renewal term. If the **Renewal Term** in the Renewal line has no value, the Renewal line will not be included in the Sales Quote. After closing page **Select Contract Lines for Renewal** with *OK*, a Sales Quote is created. The steps for [handling the Sales Quote](#create-quotes) and [preforming the Contract Renewal](#sales-order) are identical to already described process. --- ## Contracts and Services Management # Managing Contracts, Service Objects and Services Commitments Contracts, Service Objects and Services are required to perform recurring billing. **[Service Commitments](/docs/srb/masterdata/service-commitments.md)** describe the monetary content of agreements with customers and suppliers, as well as termination dates. They can only be created in a **[Service Object](/docs/srb/working-with-contracts/service-objects.md)**. The Service Object defines the essential information about the End User and the actual content, which is to be billed on a recurring basis. ## Contracts Contracts are used to organize Service Commitments for billing to customers and suppliers. If something is to be invoiced via a separate invoice, this can be set up via a separate contract. Service Commitments have as **Partners** either *Customer* or *Vendor*. Services Commitments set up as *Customer* will go into Customer Contracts, services set up as *Vendor* will go into Vendor Contracts. ## Bundle Several contract lines can be combined to a [Bundle](/docs/srb/bundles.md). A bundle is like an independent product that consists of several components. For example, a bundle can be used to combine a transfer fee and the ancillary costs (maintenance) into one bundle product. The bundle can only be used in **Customer Contracts** and sales documents (e.g. Sales Quotes / Sales Orders). ## Overview of the fields in the Service Commitments / Contract lines * The **Service Start Date** describes the date from which the Service Commitment is valid and can be invoiced. *The **Service End Date** is the date the Service Commitments ends and can no longer be billed. The date can be entered manually when a Service Commitments is terminated. * **Planned Service Commitments exist** shows that a [Contract Renewal](/docs/srb/working-with-contracts/contract-renewal.md) has been performed for this Service Commitment, but the renewal is not yet valid because the Service Commitment has not yet been fully invoiced. * The **Next Billing Date** indicates the due date of the next billing. The date is automatically recalculated during the billing run. The date is *grayed out* if invoiced to Service End Date. * The **Calculation Base Amount** is the basis of valuation of the Service Commitments. When selling an item with additional recurring Service Commitments, the Calculation Base Amount is the value of the item. * The **Billing Rhythm** specifies the Dateformula for rhythm in which the service is invoiced. Using a Dateformula rhythm can be, for example, a monthly, a quarterly or a yearly invoicing. * The **Calculation Base %** is the percentage from the **Calculation Base Amount** which is used to price the Service Commitment. * The **Price** is calculated from the **Calculation Base Amount** and the **Calculation Base %**. It is always valid for the entire **Calculation Base Amount**. I.e. it is an annual price if a year is entered in Calculation Base Period and a monthly price if a month is entered in Calculation Base Period. * The **Discount %** indicates the percentage discount for the Service Commitments. * The **Discount Amount** indicates the discount applied to the Service Commitments. * The **Service Amount** is the result of the Price, Discount, and Quantity of the Service Object. * The **Calculation Base Period** indicates the period to which the Service Amount applies. For example, enter 1M if the amount refers to one month or 12M if the amount refers to one year. **Invoicing via** specifies whether the service is charged recurrently or only stores information about the sale (e.g. for warranty extensions). Service Commitments with the *Contract* option can be called into contracts and billed recurring. *The **Partner** specifies whether the Service Commitments are in Accounts Receivable or Accounts Payable. Accordingly, Service Commitments can be called into Customer/Vendor Contracts and invoiced via A/P or Sales Invoices. * The **Contract** indicates the contract through which the Service Commitments will be billed. * The **Initial Term** indicates the minimum term of the Service Commitments. If the Initial Term is filled and no **Subsequent Term** is entered, the **Service End Date** is automatically set to the end of the Initial Term. *The **Subsequent Term** specifies the duration of the automatic extension after the Initial Term. In addition, it determines the rhythm of updating **Cancellation Possible Until** and **Term Until**. If the field is blank and either the Initial Term or the Notice Period is set at the same time, the Service End Date is automatically set to the expiration date of the Initial Term or the Notice Period. * **Cancellation Possible Until** indicates the last date for timely cancellation. The date is determined by the **Initial Term**, the **Subsequent Term**, and the **Cancellation Period**. A 12 month Initial Term with a 3 month notice period means that the due date for termination is 9 months. A Subsequent Term of 12 months postpones the deadline by 12 months when the **Cancellation Possible Until** date is reached. **Period Calculation** *expected to be released with version 2024.7* Period Calculation controls how a period is determined for billing. The calculation of a month from 28.02. onwards can stretch to 27.03. (*Align to Start of Month*) or 30.03. (*Align to End of Month*). ## Invoice discounts It is possible - permanently or for a limited period - to grant a flat discount (invoice discount) for the entire contract. This can be used, for example, if the customer changes the license model or if a permanent discount on the Service Commitment is subsequently agreed. The discount can only be defined in the **[Service Commitment Templates](/docs/srb/masterdata/service-commitments.md#service-commitment-templates)** and the **[Service Commitment Packages](/docs/srb/masterdata/service-commitments.md#service-commitment-packages)**. Amounts for [Service Commitment Package Lines](/docs/srb/masterdata/service-commitments.md#service-commitment-packages) that are marked as **Discount**=*YES* will act as discounts in billing. The process of creating a Service Object and billing is identical to the established processes. When creating the Billing Proposal via **[Recurring Billing](/docs/srb/recurring-billing.md)**, billing lines created for contract lines with discounts are created with a negative quantity and therefore a negative Service Amount. This discount amount is subsequently taken into account when posting documents are created. :::info Service Commitment Package with invoice discount A Service Commitment Package in which an invoice discount is defined can only be assigned to items with **Service Commitment Option**=*Service Commitment Item*. ::: Invoice discounts are applicable to both Customer and Vendor Contracts. They are also taken into regards in Credit Memos and in Contract Deferrals. --- ## Customer Contracts A Customer Contract represents the obligations towards a customer. It is structured similarly to a sales order. The fields in the **General** fast tab contain information about the Contractor, i.e. the contact person for this contract. The lines contain detailed information about the billing of the components of the contract. In the **Delivery and Billing** fast tab, different delivery and billing recipients (from the Contractor) can be stored. * **Deviating Shipment Recipient** Another word for "shipment recipient" can also be "service recipient" in the contract context. This can be used, for example, in a partner model to record the end customer of the partner. Therefore, the Ship-to information also serves as a visual indicator when assigning new contract elements (see [Assign Service Commitments to a Customer Contract](#assign-service-commitments-to-a-customer-contract)). * **Different invoice recipient** Analogous to the sales order, a deviating invoice recipient can be entered here. This is taken into account when creating the contract invoices. :::info Contracts in master data Contracts are visible in the fact box area at the Customer, Vendor and Contact. A click on the respective cue opens the corresponding overview. ::: ## Creating a new Customer Contract A new Customer Contract is most easily created via the Customer list and the **Contract** action (under *New Document*). With this method, the relevant contact data is also immediately transferred to the newly created Contact Header. Alternatively, enter the term *Customer Contracts* in the search (*Alt+Q*) and open the list of **Customer Contracts**. A new Customer Contract can be created using the **New** function. The following steps are necessary to create a contract: 1. Select the customer. 2. Select the **[Contract Type](/docs/srb/setup/contract-types.md)** and enter a short **Description** (both entries are optional). 3. The employee responsible for the contract can be selected in the **Assigned User ID** field. The field is located in the **General** fast tab. Since it is hidden by default, it can be made visible via *Show more*. 4. Change **Currency Code**, **Payment Terms Code** and **Payment Method Code** in the **Invoice Details** fast tab if required. The details were copied from the customer in step 1. 5. Select whether a **Detail Overview** is to be output for invoices. 6. Check and, if necessary, change the details in the **Shipping and Billing** fast tab regarding the shipping recipient (**Ship-to**) and the invoice recipient (**Bill-to**). :::tip Tip **Contract Type** and **Assigned User ID** can be used as filters in **[Recurring Billing](/docs/srb/recurring-billing.md)**. Using these (and other) filters, contracts can be billed separately based on type and clerk. ::: ## Assign Service Commitments to a Customer Contract In order to bill Service Commitments, they must be assigned to a contract. New contract lines (Service Commitments) can be added to the contract using the **Get Service Commitments** action (under *Process*). The **Services Commitments without Customer Contract** page opens. Here, all Service Commitments for the customer are listed, which are to be invoiced via a contract, but are not yet assigned to a contract. The determination, which Service Commitments are shown, is based on the customer in the Service Object (see fast tab **End User** in [Service Object](/docs/srb/working-with-contracts/service-objects.md)). When called in a contract, the Contract No. is predefined in the Service Commitments (in the **Assign to Contract No.** field). If the **Ship-to Name** is the same in the Service Object and the contract, the field will be displayed formatted **boldly**. :::tip Tip Alternatively, the page **Services Commitments without Customer Contracts** can also be called up via the role center part **Service Commitments without Contracts** or via the search (*Alt+Q*). In this case, the Service Commitments are not filtered and the Contract No. is not predefined. In addition to the DYCE Role Center **Subscription & Recurring Billing**, the Role Center part is also available in the Role Centers **Company Hub**, **Business Manager**, **Service Manager**, **Sales Order Processor**, **Project Manager** and **Sales & Relationship Manager**. ::: When the Service Commitments in a contract are transferred, **Contract lines** are created. These reflect the content of the Service Commitments. Any changes to the contract lines are automatically reflected in the Service Commitments. The **Quantity** field displays the quantity of the related Service Object. :::tip Tip If no deviating ship-to party is entered in the contract at the time the first service is assigned to a Customer Contract, the ship-to party stored in the **Service Object** is transferred to the contract. This facilitates the contract creation when mapping a partner model. ::: :::info Service Commitments are usually created automatically when the shipment is posted in the sales order. The prerequisite for this is a corresponding setup in the item used or in the Service Commitment Package, respectively. ::: :::tip Tip Editing contract lines instead of Service Commitments in the individual Service Objects makes work easier. Since the Service Commitments that are to be billed together usually also belong together in terms of content, it makes sense that they are all part of the same contract. This way they can be quickly viewed and edited via the contract. ::: :::warning Text lines Manual entry of contract lines is only possible for text lines. These are only used as an internal note for the contract processor and are not processed further. The basis for a billing is always a Service Commitment. Only text lines that are marked as [Bundle](/docs/srb/bundles.md) will be included in the invoice. ::: ## Extend Contract If a contract is to be extended by an additional component as simply as possible, the action **Extend Contract** (under *Process*) is available for this purpose. It is used to create a Service Object in *only one step* and to assign the related Service Commitments to a Customer and/or Vendor Contract. The page that opens is divided into three sections. In the first part (*Vendor*), the **Vendor Contract No.** field can be used to select the Vendor Contract that is to accommodate the (possible) vendor-side Service Commitments. The field is only editable if **Extend Vendor Contract** is activated at the same time. The second part of the page (*Customer*) behaves analogously to the first part. In the third part, in the **Item No.** field, the item corresponding to the new contract element must be specified. Further specifications can be made via **Quantity** and **Provision Start Date**. The AssistEdit at **Additional Service Commitments** allows to specify optional Service Commitments of the selected item. The page behaves slightly differently depending on the way it is called. Basically, the values of the last call are saved (per user). They are used for presetting the next time the page is opened. When calling from a Customer Contract, the part *Customer* is predefined accordingly. The same applies analogously to the part *Vendor* for the call from a Vendor Contract. In both cases the contract extension is executed with a click on *OK*. :::info Call from the menu Besides the call from a Contract Card, the page can also be called directly from the menu. In this case, the values of the last call are also used as default values. However, there is no OK button available for the execution (due to system technical reasons). It is done by calling the action **Perform Extension**. This action is not visible when called from a Customer or Vendor Contract. ::: ## Invoice discounts Mapping lump sum discounts for an entire contract is explained in more detail in [this](/docs/srb/working-with-contracts/contracts-services-mgmt.md#invoice-discounts) part of the DYCE documentation. ## Closed Contract lines If the Service End Date was entered for a contract line or it was [automatically updated](/docs/srb/setup/job-queue.md), this line can no longer be billed in the future. Therefore, ended lines will no longer be displayed in the default view of the contract card. However, via the **Closed Lines** fast tab, it is possible to continue to view these lines and thus to reconstruct at a later date what was once part of the contract. The fields of a terminated line are not editable except for **Closed**. If the check mark in this field is removed, the line is moved back to the **Lines** fast tab and is thus editable again. Then, for example, the Service End Date can be adjusted. If no change is made, the line will be moved back to the **Closed Lines** fast tab the next time **Update Service Dates** is called. For more information on updating cancellation dates and deadlines and ending contract lines, please see [here](/docs/srb/working-with-contracts/service-commitment-cancellation.md). ## Merge Contract lines In the course of time, it may happen that a customer purchases similar or identical Service Commitments, e.g. as a subsequent purchase of additional users to an already existing license. In order to be able to invoice these Service Commitments together, it is possible to combine these Service Commitments using the action **Merge Contract Lines** in the line menu of the Customer Contract. Before calling the action, the contract lines to be merged must be selected. Contract lines can only be merged if the following criteria are met for all lines: * No Billing Proposal lines may exist for any of the Service Commitments. * The dimensions must be identical. * The end user details must be identical. * The items of the Service Objects must be identical. * The **Customer References** of the Service Objects must be identical. * Service Objects must not be tracked by serial number. * The **Next Billing Date** must be identical (see also the option for [harmonization of Contract elements](#harmonized-billing)). However, the following do not have to be identical: * Service Objects * Quantity * Description * Provision Start Date * Provision End Date * Service Commitments * Description * Service Start Date * Cancellation possible until * Term until :::note Note The function cannot be called for text lines. ::: The **Select Customer Contract line** page opens, in which the contract line must be selected to which the previously selected lines are to be combined. Afterwards a new Service Object (as a copy of the Service Object of the selected contract line) including Service Commitments will be created. The total quantity is taken over. The Service Commitments to be combined are [terminated](#closed-contract-lines) and the new service is added to the contract. In the old Service Objects, the **Provision End Date** field is set, if possible. ## Create invoice per Contract Normally, contract invoices in **DYCE Subscription & Recurring Billing** are created via **[Recurring Billing](/docs/srb/recurring-billing.md)**. This feature is designed to generate Billing Proposals in batch. In addition, several options are available for creating the [Posting Documents](/docs/srb/posting-documents.md) (e.g., collective invoices, etc.). Nevertheless, it may also be useful or necessary to create a contract invoice for the one contract that is currently being worked on - without first creating a Billing Proposal for it. For this use case the action **Create contract invoice** can be used. It is available both in the Customer Contracts overview and in the Customer Contract card. In the query that opens, the key date for billing (**Billing Date**) and, optionally, the date up to which billing is to take place (**Billing To**) can be specified. In addition, the **Document Date** and the **Posting Date** can be specified for the [Posting Document](/docs/srb/posting-documents.md) to be created. If the **Open document** flag is set, the created document will be opened directly afterwards. Optionally, the created document can also be posted directly (**Post document**). Except for **Billing To**, all fields are predefined with the workdate (see page **My Settings**). :::note Note The creation of a contract invoice via the method described here is only useful in individual cases. ::: ## Details for Contract invoices In the **Invoice Details** fast tab, the **Detail Overview** field per contract controls whether billing details are automatically output for each invoice. It can be differentiated whether the details should be output with or without prices (Complete / Without prices). In addition, this field serves as a criterion with regard to the creation of collective invoices, as it must have the same value for all contracts to be combined. The fields **Contractor Name in collective Invoice** and **Recipient Name in collective Invoice** determine whether and if so, which customer names are transferred to collective invoices and output there. When creating a new Customer Contract, the **Origin Name for collective Sales Invoice** field from [setup](/docs/srb/setup/general.md#invoice-details) is interpreted. However, the setting can be made per contract. Decisive for the creation of the collective invoice are the fields of the respective Customer Contract. ## Harmonized Billing If several Service Commitments with a longer Billing Rhythm (e.g. 12 months) are purchased by the customer at different times and invoiced via the same contract, the invoicing date of the services is usually different. If the customer wishes to have aligned billing on a *billing date*, the **Harmonized Billing Customer Contracts** indicator from the [Contract Type](/docs/srb/setup/contract-types.md) can be used for this purpose. If this flag is set for the Contract Type of the Customer Contract, the **Billing Base Date** and **Default Billing Rhythm** fields (in the *Harmonized Billing* group in the **Shipping and Billing** fast tab) are editable. When the first Service Commitment is added to the contract, the fields are predefined based on that data. However, they can be changed manually. When creating the Billing Proposal lines, a check is made for each Service Commitment to see if it is connected to a contract being billed in a harmonized manner. If yes, the *harmonization fields* will be considered accordingly. The *harmonization fields* will be updated when adding, deleting and modifying a Service Commitments, if applicable. :::tip Tip If Service Commitments with a longer Billing Rhythm (e.g. 12 months) are added to a contract whose **Next Billing Date** is during the year, and these Service Commitments (and all those to come) should generally only be billed by the end of the year, the **Billing Base Date** can be reset to January 1st of the year. ::: ### Special case: Deletion of the first Billing Proposal There is a well-known special case in which manual intervention by the user is required: A contract is to be billed harmonized (e.g. per calendar year). Therefore, the **Billing Base Date** in the Contract header (in the *Shipping and Billing* fast tab) is set to *January 1st* of the current year. Service Commitments will be added during the course of the first year. If a Billing Proposal is now created within and for the first year *and subsequently deleted*, the **Billing Base Date** will be overwritten with the *oldest* **Next Billing Date** from the Contract lines (Service Commitments). This cannot be avoided due to the automatic updating of Service Commitments and only occurs as long as the contract has never been billed. After the first billing, the behavior then no longer occurs. In this case, the **Billing Base Date** must be manually reset to *January 1st* of the current year. ## Linked information Linked information can be called from the contract. In the menu (in the *Related* group) all invoices and credit memos can be accessed. In the menu group *Related / Customer Contract* the **Contract Deferrals** can be viewed if the postings in the contract are deferred periodically. Using the line menu *Contract Line* the **Billing Lines** and the **Archived Billing Lines** can be displayed. The information is opened for the selected contract line. The **Archived Billing Lines** can be opened in the posted invoice and credit memo as well. --- ## Period Calculation The **Period Calculation** controls how a period is determined for invoicing. Billing for a period length of *one* month works smoothly with **DYCE Subscription & Recurring Billing**. However, if the start of the billing period is within the last three days of a month, the length of the month and the following month are not taken into account. A contract invoice issued for *one* month from February 28th (no leap year) ends with the Business Central standard calculation on March 27th (+ 1M - 1D). However, a recurring billing from the *last* day of a month should extend to the *penultimate* day of the following month to actually represent a full month. To accommodate this, there is a choice to calculate periods using the Business Central standard method or the **DYCE Subscription & Recurring Billing** method. The **Period Calculation** with the option *[Align to Start of Month](#align-to-start-of-month)* uses the Business Central standard method, whereas *[Align to End of Month](#align-to-end-of-month)* uses a different method. For all recurring billings, the option *Align to End of Month* is generally recommended. It can be set as a default in the [Service & Contracts Setup](/docs/srb/setup/general.md#default-period-calculation). ## Align to Start of Month The calculation of a month with the option *Align to Start of Month* as **Period Calculation** in the contract line uses the Business Central standard date calculation. ### Calculation of the period When calculating a whole month, the start date *plus* one month *minus* one day (CM-1D) is used to calculate the end of the period. For the calculation of two months, the start date *plus* two months *minus* one day (CM+1M-1D) is used to calculate the end of the period. |1M - 1T|2M - 1T|1Q - 1T|1Y - 1T| |:--|:--|:--|:--| |28.01.24 - 27.02.24|28.01.24 - 27.03.24|28.01.24 - 27.04.24|28.01.24 - 27.01.25| |29.01.24 - 28.02.24|29.01.24 - 28.03.24|29.01.24 - 28.04.24|29.01.24 - 28.01.25| |30.01.24 - 28.02.24|30.01.24 - 29.03.24|30.01.24 - 29.04.24|30.01.24 - 29.01.25| |31.01.24 - 28.02.24|31.01.24 - 30.03.24|31.01.24 - 29.04.24|31.01.24 - 30.01.25| |29.02.24 - 28.03.24|29.02.24 - 28.04.24|29.02.24 - 28.05.24|29.02.24 - 27.02.25| ### Price calculation The [Billing Rhythm](/docs/srb/masterdata/service-commitments.md#overview-of-the-fields-in-the-service-commitment-package) is not taken into account when calculating the price. The Billing Rhythm determines the cycle in which a contract line is invoiced (billing period) if no manual intervention is made. The price of a **Billing line** is calculated on the basis of **Price** and **Billing Base Period** in the Service Commitment or Contract line and the **Billed Base Period**. If the invoiced period is a multiple of the **Billing Base Period**, the price is multiplied accordingly. *Monthly price = 100,- (Price = 100,- Calculation Base Period = 1M)* |1M - 1T|Price|2M - 1T|Price|1Q - 1T|Price|1Y - 1T|Price| |:--|:--|:--|:--|:--|:--|:--|:--| |28.01.24 - 27.02.24|100|28.01.24 - 27.03.24|200|28.01.24 - 27.04.24|300|28.01.24 - 27.01.25|1200| |29.01.24 - 28.02.24|100|29.01.24 - 28.03.24|200|29.01.24 - 28.04.24|300|29.01.24 - 28.01.25|1200| |30.01.24 - 28.02.24|100|30.01.24 - 29.03.24|200|30.01.24 - 29.04.24|300|30.01.24 - 29.01.25|1200| |31.01.24 - 28.02.24|100|31.01.24 - 30.03.24|200|31.01.24 - 29.04.24|300|31.01.24 - 30.01.25|1200| |29.02.24 - 28.03.24|100|29.02.24 - 28.04.24|200|29.02.24 - 28.05.24|300|29.02.24 - 27.02.25|1200| If periods are invoiced, that do not correspond to a multiple of the **Billing Base Period**, *days* (as the next smaller unit) are always used for the price calculation. Depending on the **calendar month** and the **Billing Base Period**, a different number of days is used as the basis. In a calendar year that is not a leap year, the number of days is 31 in January, 28 in February and 90 in the first quarter (01.01.25 - 31.03.25). ```math Price \ of \ the \ Billing \ lines = \sum\limits_1^n \frac{Price \ of \ Contract \ lines}{Number \ of \ days \ in \ the \ started \ period} * Days \ to \ be \ invoiced \ in \ the \ started \ period ``` |Start - End|Price|Billing Base Period|Billing Rhythm|Invoiced Period|Price of the Billing Lines| |:--|:--|:--|:--|:--|:--| |01.01.2023 - 15.01.2023|100,-|1M|1J|15 von 31 Tagen|100/ 31 * 15 = 48,387| |01.02.2023 - 14.02.2023|100,-|1M|1J|14 von 28 Tagen|100 * 14 / 28 = 50,-| |01.01.2023 - 14.02.2023|100,-|1M|1J|1M + 14 Tage|100/ 31 * 31 + 100 * 14 / 28 = 150,-| |31.01.2023 - 01.03.2023|100,-|1M|1J|1M + 2 Tage|100,- + 100,- * 2/ 28 = 107,143 | |01.01.2023 - 14.01.2023|100,-|1Q|1J|14 von 90 Tagen|100/ 90 * 14 = 15,556| |01.01.2023 - 14.04.2023|100,-|1Q|1J|1Q + 14 von 91 Tagen|100/ 90 * 90 + 100 * 14 / 91| |28.02.2023 - 14.06.2023|100,-|1Q|1J|1Q + 18 von 92 Tagen|100/ 92 * 92 + 100 * 18 / 92 = 119,565| The price of a contract line is based on the period length in **Billing Base Period** (e.g. 1 month). *n* corresponds to the number of periods included. In the third example, one and a half months are invoiced (whole of January + half of February). Accordingly, the price for January and February is calculated separately and then added up. 01.01.2023 - 31.01.2023 is a whole month. The price is 100,- for the month. 01.02.2023 - 14.02.2023 are 14 days. A whole month would be 28 days (01.02.2023 - 28.02.2023). The price for the second month is therefore calculated pro rata: 14 / 28 * 100 = 50,-. The price for the entire period invoiced corresponds to the sum of the partial periods: 100,- + 50,- = 150,- ## Align to End of Month If the **Service Start Date** and the **Next Billing Date** are within the last 3 days of a month, the period is determined from the end of the month. This means, that a Contract line that is invoiced from the last day of a month for *one* month, is invoiced up to the penultimate day of the following month. This happens regardless of how long the respective months are. This type of Period Calculation guarantees that the 13th monthly invoice starts on the same day (one year later). Apart from that, this type of Period Calculation works in the same way as *Align to Start of Month*, i.e. the **Next Billing Date** determines the first day of the next billing. *Monthly price = 100,- (Price = 100,- Billing Base Period = 1M)* |1M - 1T|2M - 1T|1Q - 1T|1Y - 1T| |:--|:--|:--|:--| |28.01.24 - 27.02.24|28.01.24 - 27.03.24|28.01.24 - 27.04.24|28.01.24 - 27.01.25| |29.01.24 - 26.02.24|29.01.24 - 28.03.24|29.01.24 - 27.04.24|29.01.24 - 28.01.25| |30.01.24 - 27.02.24|30.01.24 - 29.03.24|30.01.24 - 28.04.24|30.01.24 - 29.01.25| |31.01.24 - 28.02.24|31.01.24 - 30.03.24|31.01.24 - 29.04.24|31.01.24 - 30.01.25| |29.02.24 - 30.03.24|29.02.24 - 29.04.24|29.02.24 - 30.05.24|29.02.24 - 27.02.25| ### Calculation of prices The price calculation is carried out using exactly the same logic as [above](#price-calculation). Only the period lengths are potentially different. *Monatspreis = 100,- (Preis = 100,- Berechnungsbasis Zeitraum = 1M)* |1M - 1T|Preis|2M - 1T|Preis|1Q - 1T|Preis|1Y - 1T|Preis| |:--|:--|:--|:--|:--|:--|:--|:--| |28.01.24 - 27.02.24|100|28.01.24 - 27.03.24|200|28.01.24 - 27.04.24|300|28.01.24 - 27.01.25|1200| |29.01.24 - 26.02.24|100|29.01.24 - 28.03.24|200|29.01.24 - 27.04.24|300|29.01.24 - 28.01.25|1200| |30.01.24 - 27.02.24|100|30.01.24 - 29.03.24|200|30.01.24 - 28.04.24|300|30.01.24 - 29.01.25|1200| |31.01.24 - 28.02.24|100|31.01.24 - 30.03.24|200|31.01.24 - 29.04.24|300|31.01.24 - 30.01.25|1200| |29.02.24 - 30.03.24|100|29.02.24 - 29.04.24|200|29.02.24 - 30.05.24|300|29.02.24 - 27.02.25|1200| ```math Price \ of \ the \ Billing \ lines = \sum\limits_1^n \frac{Price \ of \ Contract \ lines}{Number \ of \ days \ in \ the \ started \ period} * Days \ to \ be \ invoiced \ in \ the \ started \ period ``` |Start - End|Price|Billing Base Period|Billing Rhythm|Invoiced Period|Price of the Billing Lines| |:--|:--|:--|:--|:--|:--| |01.01.2023 - 15.01.2023|100,-|1M|1J|15 von 31 Tagen|100/ 31 * 15 = 48,387| |01.02.2023 - 14.02.2023|100,-|1M|1J|14 von 28 Tagen|100 * 14 / 28 = 50,-| |01.01.2023 - 14.02.2023|100,-|1M|1J|1M + 14 Tage|100/ 31 * 31 + 100 * 14 / 28 = 150,-| |31.01.2023 - 01.03.2023|100,-|1M|1J|1M + 2 Tage|100,- + 100,- * 2/ 28 = 107,143 | |01.01.2023 - 14.01.2023|100,-|1Q|1J|14 von 90 Tagen|100/ 90 * 14 = 15,556| |01.01.2023 - 14.04.2023|100,-|1Q|1J|1Q + 14 von 91 Tagen|100/ 90 * 90 + 100 * 14 / 91 = 115,385| |28.02.2023 - 14.06.2023|100,-|1Q|1J|1Q + 15 von 92 Tagen|100/ 92 * 92 + 100 * 15 / 92 = 116,304| ### Leap year The period calculation works almost the same in leap years as in normal years. The only difference is that 29.02. is the last day in February. 29.02.2024 - 30.03.2024 corresponds to one month. 29.02.2024 is the last day of February and 30.03.2024 is the penultimate day of March. --- ## Price Update Regular price updates of contractually agreed, recurring Service Commitments are completely normal in times of subscription models. With **DYCE Subscription & Recurring Billing**, price updates for contractual Service Commitments can be easily planned and applied. Contract prices can be updated in three different ways: * Increase (or decrease) the price to a percentage * Increasing or decreasing the Calculation Base % by a percentage * Updating the prices of recurring Service Commitments with the list prices of the items The Contract lines that are to receive a price update can be filtered according to all fields in the Contract, Service Commitment and Service Objects. Templates can be used to save the filters and price update methods, predefine when the price update is to take effect, until when Contract lines are to be included and how long the price is not to be changed after the update (price binding agreement). On the **Contract Price Update** page, a price update proposal is created with the selected template. All proposed price updates can be checked here. Grouping the proposal lines by contract or customer increases readability. After checking, all price updates can be applied with one click. Future **planned price updates** do not take effect immediately. A price increase on 01.01. should not change the price in December. **Planned Service Commitments** are created specifically for this purpose. The planned price update can be displayed to the user, but it does not require any manual intervention. The price update will take effect automatically as soon as the Contract line has been invoiced to the cut-off date. If a period in which a price update was applied is credited, the price is automatically reset to the original price. At the same time, a **Planned Service Commitment** is automatically created, which saves the reset price update. If the period is invoiced again, the price update is re-applied. In this way, the prices of the periods are retained. Invoices and credit notes can be created with the original amounts. ## Templates The **Contract Price Update** page (*Alt+Q*) is used to create price update proposals. In order to create a proposal, a template must be used. The list of **Price Update Templates** can be opened via the AssistEdit in the **Price Update Template** field. ### Filters Templates can be used to filter Service Commitments. The **Partner** specified in the template determines whether Vendor Contracts or Customer Contracts are included in the price update. The filters are created using the **Contract filter**, **Service filter** and **Service Object filter** fields. Clicking on one of the fields opens the filter page. :::tip Important When creating price update proposals, some filters are applied automatically: * Service Commitments with the **Usage Based Billing** indicator are not taken into account. * Only Service Commitments with **Invoicing via** *Contract* are taken into account. * Contract lines that have been **Closed** are not taken into account. * Contract lines marked with **Exclude from Price Update** are not taken into account. In addition to these automatic filters, it is recommended to enter `<>''` (not equal to empty) in the Service Commitment filter **Contract**. This prevents Service Commitments, that are not yet assigned to a contract or have been deleted from the contract after being invoiced completely, from being included in the price update. The **Closed** field only exists in the Contract lines. Accordingly, the automatic filter does not apply in these cases. It is also advisable to exclude Service Commitments with the **Discount** indicator in the Service Commitment filter. Discounts can be changed with the price update if so desired. However, this procedure is rather unusual. If Service Commitments with a limited term that could potentially be the subject of contract renewal are to be excluded, Service Commitments must be filtered for an empty Service End Date. Filters may need to be changed after changes have been made to the template. For example, if a Customer Contract is filtered and the partner is changed to *Vendor*, the filter will remain on the Customer Contract. When a proposal is created, no services are found as there are no services with partner *Vendor* in a Customer Contract. ::: ### Price Update Method There are three **Price Update Methods** * **Price by %** Increases or decreases the price of the Contract lines by the percentage in **Update Value %**. The use of negative values is possible. A price update of 2% for a Contract line with a price of 100,-, will increase the price to 102,-. * **Calculation Base by %** Sets the Calculation Base % to the value in **Update Value %**. A price update to 20% sets the Calculation Base % to 20%. With a filter on the old Calculation Base %, the percentages of all Service Commitments can be increased to the new value with just a few clicks. **Recent Item Price** Updates the Calculation Base % in the Service Commitments with prices from the Sales Price List. The prices for the Service Commitments are determined for the items in the Service Objects and the date in **Perform Update on**. Price updates planned for the future thus receive the prices planned in the Sales Price List. The discount % in the Sales Price List is not taken into account in the query, as these are often agreed on individually with customers. :::warning Important If a price would be set to 0 or become negative due to a price update, no proposal line is created for the Service Commitment. ::: ### Perform update on (Dateformula) The dateformula presets **Perform Update on** in the **Contract Price Update** page. The date **Perform Update on** determines when the price update should take effect. However, price updates cannot take effect on any date. The price for periods already invoiced cannot and should not be changed. Accordingly, the price change will not take effect until a later date. Thus, the price update de facto becomes effective on the last day of the last period invoiced. This means that the old price applies to the period already invoiced and the new price applies to the subsequent period not yet invoiced. This avoids discrepancies in billing and credit notes. The same applies to periods that have not yet been invoiced. If **Perform Update on** is 15.01., then all days up to 15.01. must be charged at the old price. How exactly the date determination works is explained in more detail in the paragraph **[Contract Price Update](#contract-price-update)**. :::note Note If **Perform Update on** equals **Next Billing Date** (and **Next Price Update**), the price update is applied out immediately. In the archived Service Commitments, **Perform Update on** is saved as **Next Billing Date** minus 1 day. By placing the price update in the previous period, the current period can be invoiced and credited with the new prices without the price update being reset. ::: ### Include Contract Lines Up To Date (Dateformula) The dateformula presets **Include Contract Lines Up To Date** in the **Contract Price Update** page. The date in **Include Contract Lines Up To Date** is compared with the date in **Next Price Update** in the Service Commitments to determine whether the Service Commitment is eligible for a price update. In each Service Commitment / Contract line, the **Next Price Update** field indicates when the next price update can be applied. This displays the end of the price binding periods and prevents the price from being changed several times in succession by mistake. The **Next Price Update** is calculated from the **Service Start Date** and the **Price Binding Period** in the line Service Commitment Package line when the Service Commitment is created. In the event of a price update, the **Next Price Update** date is recalculated with the **Price Binding Period** from the template and changed in the Service Commitment. :::info Info The **Next Price Update** date can be changed manually at any time. The price of a Service Commitment can be changed at any time regardless of the **Next Price Update** date. If a Service Commitment is not yet eligible for a price update again according to **Next Price Update**, no proposal line is created. ::: ### Price Binding Period The **Price Binding Period** determines how long the Service Commitment should not be taken into account after a price update. If the price is only to be increased once within the a year, the Dateformula *1Y* is entered. When the price update is carried out, the **Next Price Update** is automatically changed in the Service Commitment. The new date **Next Price Update** is calculated from **Perform Update on** plus **Price Binding period** (e.g. 31.12.2023 + 1Y = 31.12.2024). ### Grouping The **Grouping** determines how lines are displayed in the **Contract Price Update** page. The price update proposals can be displayed *ungrouped*, grouped by *Contract* or grouped by *Customer*. ## Contract Price Update Proposals for price updates can be created, checked and carried out on the **Contract Price Update** page. The page can be opened via the search (*Alt+Q*). The **Price Update Template**, **Include Contract Lines Up To Date** and **Execute update on** must be entered in order to create a proposal. ### Create proposal The **Create proposal** action creates proposal lines for all Service Commitments in the filter. Each line contains the current price, amount, Calculation Base % as well as the new values and the difference between the two. Fields such as Calculation Base %, Quantity, Discount %, etc. can be displayed using **Personalization**. When created, **Perform update on** and **Next Price Update** are entered in each proposal line. This means that the proposal can easily be extended with further templates before the price updates are applied. If filtering the Service Commitments in a template is too complex or not possible, we recommend using several templates. The templates can be selected one after the other in order to add the additional Service Commitments to the proposal in the new template (e.g. prices in Service Commitments younger then xx.xx. will be increased by 2% but older Service Commitments are only increased by 1%). :::warning Important A maximum of one proposal line is created per Service Commitments and it is not updated when the **Create proposal** action is used again. If the Service Commitment is the subject of several templates, the proposal for the price update from the first template is retained and is not overwritten by subsequent templates. This also applies to the **Perform Update on** and **Next Price Update** fields. Proposal lines are proposals for a price update. No update of the Service Commitments / Contract lines has been done at this point. Based on the data, the proposal may differ from the actual update in regards to the date **Perform Update on**. It is therefore possible to set a date in the past for **Perform Update on**. However, the price in periods already invoiced will not be changed. If a planned Service Commitment with **Type of update** *Price update* or *Contract extension* exists, no proposal line is created for this Service Commitment. The planned Service Commitments would overwrite the price update in any case. I would come down to the sequence of execution, which is avoided at this point of time. A price update and contract renewal are potentially binding agreements, which is why the combination is currently avoided when **Create Proposal** is executed. ::: ### Dynamic due date for price updates If the **Perform Update On** date in **Contract Price Update** is empty when **Create proposal** is executed, the first possible **Perform Update On** date is determined and entered for each proposal line. The **Next Price Update** date in the proposal line is determined based on the **Perform Update On** date and the dateformula in the template. The next possible date for a price update is determined based on the **Next Billing Date** and **Next Price Update** fields in the contract lines. The later date is used for **Perform Update On** to avoid price increases in periods already invoiced or before the next scheduled date. ### Delete proposal lines The template used to create the proposal line is saved in the line. Accordingly, it is not only possible to delete the selected or all proposal lines, but also the lines that were created with a specific template. This is particularly helpful if, for example, the **Perform Update on** was set incorrectly. The **Delete Line** action deletes all selected lines. The **Delete Proposal** action opens a page that asks whether the entire proposal or only the lines belonging to the current template should be deleted. Heading lines are automatically deleted if there are no more related proposal lines. ### Perform price update The **Perform price update** action performs the price update and deletes all proposal lines afterwards. If the price update can be applied immediately, the following fields are updated in the Service Commitment/ Contract lines: * Calculation Base % * Calculation Base * Discount % * Price (is recalculated from Calculation Base Amount and Calculation Base %) * Service Amounts (recalculated from price and quantity) * Next Price Update * Price Binding Period Changes, that have been made to these fields in the meantime, are overwritten. Changes made to other fields are retained. If the price update cannot be applied immediately, planned Service Commitments are created. The price update can potentially not be applied immediately for the following reasons: * There are billing lines for a Contract line. The price update never intervenes in the current invoice run. * There is an unposted invoice or credit note. The price update does not change any documents. * **Next Billing Date** is before **Next Price Update**. If the **Next Billing Date** is before **Next Price Update** (e.g. 22.11.2023 is before 31.12.2023), there is a period that must be invoiced with the old price. The planned Service Commitment is a copy of the Service Commitment with a few deviations. The fields that are overwritten immediately are taken from the proposal line (listed above: Calculation Base %, etc.). In addition, the dates in **Perform update on**, **Perform update on** and **Price Binding Period** are copied from the proposal line. The planned Service Commitment is created with the **Type of update** *Price update*. :::info Note In the **Planned Service Commitments** list, the **Type of Update** field can be ued for filtering to obtain a list of price updates that have already been created/performed but have not yet come into effect. ::: The price update of the planned Service Commitments is automatically applied as soon as possible. When contract invoices are posted, the system checks whether there are planned Service Commitments for the contract lines invoiced and whether their price updates can be applied. If an invoice is posted, there can no longer be any billing lines or unposted documents. Accordingly, the only remaining condition is that the Service Commitments must be invoiced until the **Next Price Update** date *(Next Billing Date must not be before Next Price Update)*. If this condition is met, the same fields are updated in the Service Commitment as when the price update is applied immediately. An **Archived Service Commitment** is created for every applied price update. The archived Service Commitment is a copy of the Service Commitment before the price update with some differences worth mentioning. **Perform update on** corresponds to the **Next Billing Date** minus one day. Regardless of when the original **Perform update on** was, the update was performed at the end of the last invoiced period and is valid with the new period. Archiving exactly when the price update actually came into effect is essential for maintaining period-accurate prices. If the last period is credited, the price update must be canceled in order to be able to use the prices of the last period. The **Type of update** is set to *Price update* in the **Archived Service Commitment**. :::warning Important If the date in **Perform Update on** is before **Next Price Update**, the price update can still be applied, if the Service Commitment has been invoiced until or beyond **Next Price Update**. The **Perform Update on** date is changed to **Next Billing Date** - 1D in the archived Service Commitment because the price update only came into effect at the end of the last period. The decisive factor as to whether the price update can be applied in this case, is that the complete period for which the old price applies has been invoiced. If the price update was not applied due to existing billing lines or unposted invoices (planned Service Commitments created), the price update will not be applied if the invoice or billing lines are deleted. The price update in the planned Service Commitments is only applied when an invoice is posted. ::: **Example 1** The price update can take effect immediately. |Type|Next Billing Date|Next Price Update|Perform Update on|Price Binding Period|Price| |:--|:--|:--|:--|:--|:--| |Service Commitment before price update|01.01.2024|31.12.2023|-|1Y|Old| |Proposal Price update|-|31.12.2024|31.12.2023|1Y|Neu| |`Immediate execution`|||31.12.2023 equal to or after 31.12.2023|| |Service Commitment after price update|01.01.2024|31.12.2024|-|1Y|New| |Archived Service Commitments|01.01.2024|31.12.2023|31.12.2023|1Y|Old| :::warning Important The price update would not have been performed if the **Perform update on** date had been 02.01.2024. The **Next Billing Date** describes the next day that can be calculated. This includes this day. This means that 01.01.2024 would have to be invoiced at the old price before the price update can take effect. ::: **Example 2** The price update cannot take effect immediately. A planned Service Commitment is created to save the price update and apply it later automatically (when posting an invoice as soon as the conditions are met). |Type|Next Billing Date|Next Price Update|Perform Update on|Price Binding Period|Price| |:--|:--|:--|:--|:--|:--| |Service Commitment before price update|01.01.2024|31.12.2023|-|1Y|Old| |Proposal Price update|-|31.12.2024|15.01.2024|1Y|Neu| |`Planned Service Commitments necessary`|||01.01.2024 is before 15.01.2024|| |`Planned Service Commitment|01.01.2024|31.12.2024|15.01.2024|1Y|New| |`Invoice 01.01.2024 - 31.12.2024`||||Old| |Service Commitment after price update|01.01.2025|31.12.2024|-|1Y|New| |Archived Service Commitments|01.01.2025|31.12.2024|31.12.2024|1Y|Old| :::warning Important Price updates and **Perform Update on** in planned Service Commitments do not affect the invoicing of Service Commitment. The price update will be applied automatically after invoicing it as soon as this is possible. The **Next Price Update** date will not be adjusted to the changed date when the price update actually came into effect. ::: ## Reset price update / Credit Memo Regardless of price updates, a credit memo is always created with the same amount as the invoice. In addition, price updates are reset to ensure that prices stay correct in each period. When a contract invoice is credited, the system checks whether a price update has taken place in the credited period. If a price update has taken place, it is reset. Price updates never take effect in the middle of invoiced periods. A Service Commitment is calculated at exactly one price. If a price update falls within the invoice period, it will not actually take effect until after the invoiced period. Example **Perform Update on** 15.01.2024 Invoice 01.01.2024 - 31.01.2024 The period 01.01. - 14.01.2024 must be invoiced at the old price. As price updates do not affect invoicing, the entire period will be invoiced at the old price. The price update will take effect at the end of the invoiced period (31.01.2024). When this invoice is credited again, the **Next Billing Date** will again be 01.01.2024. On this date, the old price was originally valid and the price update had not yet come into effect. Accordingly, the price update will be canceled and the original prices as of 01.01.2024 will be restored. The contract invoices can be issued with the original prices without the user having to do anything. When the price update is withdrawn, a planned Service Commitment is created at the same time, which reapplies the price update (31.01.2024) when the period is invoiced again. :::warning Important The planned Service Commitment that is created together with a credit memo has the date 31.01.2024 in **Perform update on** in the example above. The reason for this is that the price update did not actually come into effect until 31.01.2024 and only applies to the next period. For **Perform Update on**, the **Next Billing Date** after the invoice is never used, as otherwise the price update would be incorrectly canceled in the following period. Example **Perform Update on** 15.01.2024 Invoice 01.01.2024 - 31.01.2024 Archived Service Commitment **Perform Update on** 01.02.2024 Invoice 01.02.2024 - 29.02.2024 (new price applies without restriction for the period) Credit Memo --> The price update should not be canceled. If prices have been edited manually, they will be used when the price update is canceled and re-applied. In this case, however, it is more difficult to trace the steps using archived and planned Service Commitments. If the prices were changed after the credit memo, they will be overwritten by the price update. The price update can be canceled/deleted after the credit memo by deleting the planned Service Commitments. ::: --- ## Cancelling Service Commitments # Termination of Contract components All contract lines contain information about their validity and termination dates. Thus, they can be terminated before the expiry or termination dates can be changed. If validity and notice periods are not set, the contract lines are valid indefinitely or can be terminated at any time. ## Cancellation of a Contract Line / or Service Commitment In the field **Service End Date** a date can be maintained, from which the contract line should no longer be charged. After this date, the contract line will automatically no longer be considered for billing. The Service End Date can be independent of **Cancellation Possible Until** and **Term Until**. If there is no agreement with the supplier or customer, the field will be left blank. If the **Service End Date** is one day prior to the **Next Billing Date**, the contract line is considered terminated. When the action **Update Service Dates** is executed, the contract line is marked as [closed](/docs/srb/working-with-contracts/customer-contracts.md). :::info If a **contract line** has been billed by mistake because the **Service End Date** was not maintained, it cannot simply be terminated retroactively. Otherwise, the contract line would be considered billed for a period after the **Service End Date**. Therefore, a credit memo must first be issued. The credit memo resets the **Next Billing Date**. The contract line can then be terminated. This ensures that the process of crediting and ending the contract line is followed. ::: ## Termination dates and deadlines The **Cancellation Possible Until** date provides information on when a contract line can be cancelled in due time. The **Term Until** date provides information about the minimum time until which a contract line will be charged or should be charged, even if it has been terminated. The **Subsequent Term** specifies the duration of the automatic extension after the Initial Term. In addition, it determines the rhythm of updating **Cancellation possible until** and **Term until**. If the field is blank and either the **Initial Term** or the **Notice Period** is set at the same time, the **Service End Date** is automatically set to the expiration date of the **Initial Term**. For example, if there is a contract line with **Next Billing Date** 01.01.YYYY that renews annually and has a notice period of 3 months, the termination dates will be as follows: * **Term until** is 31.12.YYYY. The contract line should be charged for the whole year even if it is terminated in due time. * **Cancellation possible until** is 30.09.YYYY. The contract line can be terminated in due time up to this date. If the cancellation is received later, the contract line will be billed for another year. :::tip Tip If a contract line is cancelled by the customer, the date until which it will be invoiced can be entered directly in the contract line. If the cancellation takes place after the deadline, the regular end can be entered or as a gesture of goodwill the deadline can be ignored. This can be especially helpful if the customer wishes to upgrade, for example, and the old contract line should therefore no longer be billed. ::: If **Cancellation possible until** or **Term until** is changed, the other field will be recalculated. The **Cancellation period** is always used for this calculation. The next time the dates are updated, the entered values will be used for the calculation. The **Update Service Dates** action can be used to update the notice dates. The function can be called both in the contract and in the Service Object. For smooth operation, the function should always run in the Job Queue. :::info Update of termination dates The update of the termination dates can be added to the Job Queue via **DYCEUpdateServCommTermDates** (Codeunit 70920758) to run automatically and autonomously. It is sufficient to run the codeunit once a day outside business hours. The functionality corresponds to calling the action **Update Service Dates** in the contract card. ::: --- ## Service Objects Service Objects represent a history of products sold to a customer. They contain all information related to the delivered item, such as * master data (Item No., Description) * Details of the sale (customer, delivery recipient, invoice recipient) * Quantity, date of provision and date of next settlement * All Service Commitments (sales and Service Commitments including prices, terms and cancellation periods). A Service Object can be created automatically from a Sales order using the [Shipment](/docs/srb/sales/sales-service-commitments.md) (see **[Service Commitment Option](/docs/srb/masterdata/items.md)** field on the Item card for prerequisites). When a Service Object is created on shipment, the information regarding the End User and the Invoice Recipient is taken from the order and the delivery. This also includes the **Your Reference** field, which is transferred to the **Customer Reference** field. Alternatively, a Service Object can also be entered manually by creating a new record (action **New** in the **Service Objects** page) and filling in the fields on each fast tabs. This may be necessary, for example, in the case of a manual transfer of equipment or licenses. The Service Object with the associated Contract Commitments forms the basis for the Customer and Vendor Contracts and their periodic [Recurring Billing](/docs/srb/recurring-billing.md). :::info Service Objects in master data Service Objects are visible in the fact box area at the Customer, Vendor and Contact. A click on the respective cue opens the corresponding overview. ::: The following information is required to manually create a Service Object: 1. **No.** can be filled via a number series. 2. **Item No.** is used to define the device/software/license/user/... that will be billed recurrently. Only items with the **Service Commitment Option** *Sales with Service Commitments* or *Service Commitment Item* can be selected. 3. The **Description** is automatically taken from the item and can be edited. 4. In the **Quantity** any positive value can be entered. It specifies the number of devices/licenses etc. whose Service Commitments are to be billed recurrently. 5. The **End User** fast tab contains information (contact and customer information) about which customer has purchased the item and the Service Commitments. When creating a Service Object manually, the customer must be entered here. 6. The **Shipping and Billing** fast tab contains information about the (original) shipment of the product and whether a different invoice recipient paid for the item. The contact details of the delivery recipient from the sales order are automatically used. The Ship-to party can be changed if required (even subsequently), in the same way as for sales documents. The other delivery recipient fields are automatically updated after modification. As additional information, the **Customer Reference**, the **Version**, the **Provision Start Date** and the **Provision End Date** can be maintained, whereby the **Provision Start Date** is automatically entered when the Service Object is created via the delivery from a Sales Order. :::note Customer Reference in the Contract invoice If a Customer Reference is stored on a Service Object, this information will automatically appear below the corresponding invoice line. ::: ## Service Object with Serial Number When serial number tracked items are delivered with Service Commitments, one Service Object is automatically created for each serial number. The serial number is determined from the item tracking lines for the Sales Order line and transferred to the Service Object in the **Serial No.** field. The field on the Service Object is editable. The quantity in a serial number tracked Service Object must always be 1 and cannot be changed. In order to store a serial number for a Service Object, an item tracking must be set for the item. Changes can be tracked using the **[Archived Service Commitments](/docs/srb/working-with-contracts/so-service-commitments.md#log-changes-to-services-commitments)**. :::note Serial number in Contract invoices If a serial number is stored on a Service Object, this information will appear depending on the [Invoice Details](/docs/srb/setup/general.md#invoice-details) set in the setup. ::: ## Service Object Attributes With the help of attributes, items can be described in detail using any number of criteria. The same is possible for Service Objects. Two fact boxes are available for this purpose - both in the card and in the overview. The fact box **Item Attributes** shows the attributes that are stored for the item of the Service Object. In addition, the characteristics specific to a concrete Service Object can be stored and displayed via the **Service Object Attributes** fact box. To maintain the specific characteristics of a Service Object, open the **Service Object Attribute Values** page either via the dropdown menu of the fact box or via the **Attributes** action. In addition, it is possible to define a feature as **Primary** here. The primary attribute is displayed in the Service Object card in the *General* fast tab (*Show more*). Here, the description of the primary attribute is used dynamically as the field name. It is possible to output the primary attribute of a Service Object when billing the related Service Commitments in the Contract invoice. The configuration required for this can be done [here](/docs/srb/setup/general.md#invoice-details). For the description of the attributes, translations can be stored analogous to the standard of Business Central. For more information on attributes, please refer to this part of the Microsoft documentation. ## Entering Service Commitments in a Service Object An item is required to create Service Commitments, since Service Commitments themselves cannot be created manually. An item must therefore be entered in the Service Object in order to create Service Commitments. The **Assign Service Commitments** function can be used to view the **Service Commitment Packages** with the item's Service Commitments. The function opens the selection window of the same name. Here, **Service and Calculation Start Date** can be entered and Service Commitment Packages can be selected. Only Service Commitment Packages that have not yet been created as Service Commitments for the Service Object appear in the selection. For all selected Service Packages, the related Service Commitments are created in the Service Object and displayed in the **Services** fast tab. The prices from the item card are used as a basis for the price calculation. If an End User is subsequently entered, the prices in the Service Commitments are updated with the customer-specific prices on demand, if necessary. If the End User is assigned before the Service Commitments are created, the customer-specific prices are used directly. :::info A Service Object can only be deleted if all related Service Commitments are deleted. The Service Commitments are therefore - if possible - also deleted when the Service Object is deleted. ::: ## Quantity change For Service Objects whose items are not configured for item tracking (lot or serial number obligation), the quantity can be changed directly in the Service Object. This will result in a recalculation of the Service Amounts in the associated Service Commitments and contract lines. It is not possible to change the quantity for Service Objects whose items are configured for item tracking (lot or serial number obligation). Service Objects with lot number tracking retain the quantity from the delivery (or that of the initial entry). Service Objects with serial number tracking can only be created with quantity=*1*. ## Variants As with items, variants can be used to map different characteristics of Service Objects. One common use case is different quantity scales. For example, variants for 1-10 users and for 11-25 users etc. can be used as the basis for pricing. Upon shipping a Sales Order, the variant is transferred to the Service Object. The variant can be changed in the Service Object. When the variant is changed, the prices for Service Commitments with **Partner**=*Customer* can be recalculated. --- ## Service Commitments in Service Objects # Service Commitments Service Commitments describe the monetary content of agreements with customers and suppliers as well as termination dates. In order for a Service Commitments to be billed recurrently, it must be assigned to a contract. A Service Commitment is valid if **Invoicing via** is set to *Contract* and the **Service End Date** is either blank or the **Next Billing Date** has not reached the Service End Date. Service Commitments with Invoicing via *Sales* are used to store information and are not billed on a recurring basis. If a Service Commitments is assigned to a contract, almost all changes can be made in the contract. The quantity of Service Commitments cannot be changed in the contract. :::info * If the **Next Billing Date** reaches the **Service End Date**, it will be grayed out. These Service Commitments are considered ended and can no longer be billed. * An example of a service that should not be billed recurringly but store information about the sale is a warranty extension. It is billed once through the sales order. The information about how long the extension is valid is stored in the Service Commitments. ::: ## Editing Service Commitments ### Log changes to Services Commitments Service Commitments can be edited as lines in the **[Service Objects](/docs/srb/working-with-contracts/service-objects.md)** and contracts. If any of the following fields are edited, the Service Commitments will be archived before the change is made: * Calculation Base Amount * Calculation Base % * Price * Discount % * Discount Amount * Service Amount * Billing Base Period * Billing Rhythm If the Service Amount changes due to quantity changes, the Service Commitment is also archived. In addition, changing the serial number will result in archiving, as the serial number is also present in the **Archived Service Commitments**. If archived Service Commitments exist, the field **Archived Service Commitments** in the Service Object shows *YES*. By clicking on *YES* the Archived Service Commitments are displayed (incl. the corresponding quantity of the Service Object). The timestamp and user who made the change can be viewed via the Page Inspector. :::info If several changes are made in quick succession to the same Service Commitment, only the "original" version will be archived. ::: ### Delete Service Commitments Service Commitments can be deleted if they have not yet been invoiced and are not yet assigned to a contract. If they are assigned to a contract, the contract line can be deleted to remove the assignment. If the Service Commitments have already been invoiced, they must first be terminated by setting a Service End Date before the Service Commitments can be deleted. :::tip Tip Contract lines and Service Commitments are always identical. If a contract line is edited, the change is automatically applied to the Service Commitments. ::: --- ## Vendor Contracts A Vendor Contract maps liabilities to suppliers or manufacturers. It is structured similarly to a purchase order. The fields in the **General** fast tab contain information about the contract partner, i.e. the supplier's contact person for this contract. The lines contain detailed information about the billing of the components of the contract. In the **Payment** info tab, a different payee (from the contract partner) can be stored. * **Deviating payee** Analogous to the purchase order, a deviating payee can be entered here. This is taken into account when creating the contract invoices. :::info Contracts in master data Contracts are visible in the fact box area at the Customer, Vendor and Contact. A click on the respective cue opens the corresponding overview. ::: ## Creation of a new Vendor Contract A new Vendor Contract is most simply created via the Vendor list and the **Contract** action (under *New Document*). This method will also immediately copy the relevant contact information into the newly created Contract Header. Alternatively, enter the term *Vendor Contracts* in the search (*Alt+Q*) and open the list of **Vendor Contracts**. Use the **New** function to create a new Vendor Contract. The procedure for creating a new Vendor Contract is similar to that for Customer Contracts. The following steps are necessary to create a contract: 1. Select the vendor. 2. Select the **[Contract Type](/docs/srb/setup/contract-types.md)** and enter a short **Description** (both entries are optional). 3. The employee responsible for the contract can be selected in the **Assigned User ID** field. The field is located in the **General** fast tab. Since it is hidden by default, it can be made visible via *Show more*. 4. Change **Currency Code**, **Payment Terms Code** and **Payment Method Code** in the **Invoice Details** fast tab if required. The details were copied from the vendor in step 1. 5. If necessary, change the payee (**Pay-to**) in the Payment fast tab. ## Assigning Service Commitments to a Vendor Contract In order to bill Service Commitments, they must be assigned to a contract. New contract lines (Service Commitments) can be added to the contract using the **Get Service Commitments** action (under *Process*). The **Services Commitments without Vendor Contract** page opens. Here, all the Service Commitments for vendors are listed, which are to be invoiced via a contract, but are not yet assigned to a contract. When called in a contract, the Contract No. and the vendor are predefined in the Service Commitments (in the **Assign to Contract No.** and **Vendor** field). When the Service Commitments are transferred into a contract, **Contract Lines** are created. These reflect the content of the Service Commitments. Any changes made to the contract lines are automatically reflected in the Service Commitments. The **Quantity** field displays the quantity of the related Service Object. Alternatively, the **Services without Vendor Contracts** page can also be accessed via the Role Center or via the search (*Alt+Q*). In this case, the Contract No. and Vendor are not predefined. :::info Only Service Commitments that have *Vendor* as **Partner** can be transferred to Vendor Contracts. Since no vendor can be stored in the Service Object, vendor-side Service Commitments can be assigned to any Vendor Contract. ::: :::note Note Service Commitments are usually created automatically when the shipment is posted in the sales order. The prerequisite for this is a corresponding setup in the item used or in the Service Commitment Package. ::: ## Extend contract If a contract is to be extended by an additional component as simply as possible, the action **Extend Contract** (under *Process*) is available for this purpose. It is used to create a Service Object in *only one step* and to assign the related Service Commitments to a Customer and/or Vendor Contract. The page that opens is divided into three sections. In the first part (*Vendor*), the **Vendor Contract No.** field can be used to select the Vendor Contract that is to accommodate the (possible) vendor-side Service Commitments. The field is only editable if **Extend Vendor Contract** is activated at the same time. The second part of the page (*Customer*) behaves analogously to the first part. In the third part, in the **Item No.** field, the item corresponding to the new contract element must be specified. Further specifications can be made via **Quantity** and **Provision Start Date**. The AssistEdit at **Additional Service Commitments** allows to specify optional Service Commitments of the selected item. The page behaves slightly differently depending on the way it is called. Basically, the values of the last call are saved (per user). They are used for presetting the next time the page is opened. When calling from a Customer Contract, the part *Customer* is predefined accordingly. The same applies analogously to the part *Vendor* for the call from a Vendor Contract. In both cases the contract extension is executed with a click on *OK*. :::info Call from the menu Besides the call from a Contract Card, the page can also be called directly from the menu. In this case, the values of the last call are also used as default values. However, there is no OK button available for the execution (due to system technical reasons). It is done by calling the action **Perform Extension**. This action is not visible when called from a Customer or Vendor Contract. ::: ## Invoice discounts Mapping lump sum discounts for an entire contract is explained in more detail in [this](/docs/srb/working-with-contracts/contracts-services-mgmt.md#invoice-discounts) part of the DYCE documentation. ## Closed contract lines If the Service End Date was entered for a contract line or it was [automatically updated](/docs/srb/setup/job-queue.md), this line can no longer be billed in the future. Therefore, ended lines will no longer be displayed in the default view of the contract card. However, via the **Closed Lines** fast tab, it is possible to continue to view these lines and thus to reconstruct at a later date what was once part of the contract. The fields of a terminated line are not editable except for **Closed**. If the check mark in this field is removed, the line is moved back to the **Lines** fast tab and is thus editable again. Then, for example, the Service End Date can be adjusted. If no change is made, the line will be moved back to the **Closed Lines** fast tab the next time **Update Service Dates** is called. For more information on updating cancellation dates and deadlines and ending contract lines, please see [here](/docs/srb/working-with-contracts/service-commitment-cancellation.md). ## Merge Contract lines In the course of time, it may happen that similar or identical Service Commitments are purchased from a supplier, e.g. as additional purchase of further users to an already existing license. In order to be able to invoice these Service Commitments together, it is possible to combine these Service Commitments using the action **Merge Contract Lines** in the line menu of the Vendor Contract. Before calling the action, the contract lines to be merged must be selected. Contract lines can only be merged if the following criteria are met for all lines: * No Billing Proposal lines may exist for any of the Service Commitments. * The dimensions must be identical. * The end user details must be identical. * The items of the Service Objects must be identical. * The **Customer References** of the Service Objects must be identical. * Service Objects must not be tracked by serial number. * The **Next Billing Date** must be identical. However, the following must not be identical: * Service Objects * Quantity * Description * Provision Start Date * Provision End Date * Service Commitments * Description * Service Start Date * Cancellation possible until * Term until :::note Note The function cannot be called for text lines. ::: The **Select Vendor Contract line** page opens, in which the contract line must be selected to which the previously selected lines are to be combined. Then a new Service Object (as a copy of the Service Object of the selected contract line) including Service Commitments will be created. The total quantity is taken over. The Service Commitments to be combined are [terminated](#closed-contract-lines) and the new service is added to the contract. In the old Service Objects, the **Provision End Date** field is set, if possible. ## Create invoice per contract Normally, contract invoices in **DYCE Subscription & Recurring Billing** are created via **[Recurring Billing](/docs/srb/recurring-billing.md)**. This feature is designed to generate Billing Proposals in batch. In addition, several options are available for creating the [Posting Documents](/docs/srb/posting-documents.md) (e.g., collective invoices, etc.). Nevertheless, it may also be useful or necessary to create a contract invoice for the one contract that is currently being worked on - without first creating a Billing Proposal for it. For this use case the action **Create contract invoice** can be used. It is available both in the Vendor Contracts overview and in the Vendor Contract card. In the query that opens, the key date for billing (**Billing Date**) and, optionally, the date up to which billing is to take place (**Billing To**) can be specified. In addition, the **Document Date** and the **Posting Date** can be specified for the [Posting Document](/docs/srb/posting-documents.md) to be created. If the **Open document** flag is set, the created document will be opened directly afterwards. Optionally, the created document can also be posted directly (**Post document**). Except for **Billing To**, all fields are predefined with the workdate (see page **My Settings**). :::note Note The creation of a contract invoice via the method described here is only useful in individual cases. ::: ## Linked information Linked information can be called in the contract. In the menu (in the *Related* group) all invoices and credit memos can be accessed. In the menu group *Related / Vendor Contract* the **Contract Deferrals** can be viewed if the postings in the contract are deferred periodically. Using the line menu *Contract Line* the **Billing Lines** and the **Archived Billing Lines** can be displayed. The information is opened for the selected contract line. The **Archived Billing Lines** can be opened in the posted invoice and credit memo as well. --- ## Comment lines on contract invoices In a Business Central standard customer subscription contract, comment lines serve as internal notes and are not transferred to contract invoices. **DYCE Feature Suite for Subscription Billing** extends this behavior with the **Attached to Line No.** field, which allows comment lines to be linked to a specific billable contract line (of type *Item* or *G/L Account*). When an invoice is created, attached comment lines are transferred to the invoice alongside the contract line they belong to, preserving the visual context for the customer. ## Attaching a comment line The **Attached to Line No.** field appears as the last field on the contract lines subpage and is only editable for comment lines. For all other line types (Item, G/L Account), the field is read-only and cleared automatically. To attach a comment line to a contract line, use the lookup on the **Attached to Line No.** field. A selection page opens listing all contract lines of the same contract with a type of *Item* or *G/L Account*. After selecting a line and confirming with *OK*, the **Attached to Line No.** field is set to the line number of the selected contract line. :::tip Automatic assignment When a new comment line is inserted directly above or below an existing Item or G/L Account line, the **Attached to Line No.** field is set automatically to that adjacent line. This reduces manual effort when adding context-specific comments to billing lines. ::: ## Invoice transfer When a contract invoice is created, comment lines with a value in **Attached to Line No.** are included in the invoice and positioned relative to their parent contract line. Comment lines without an attached billing line (i.e., **Attached to Line No.** is empty) are not transferred to invoices. --- ## Preassigning contracts # Preassigning contracts in Sales After a subscription has been shipped, the subscription lines must be assigned to a Customer subscription contract so that they can then be invoiced. This handling from the Business Central Standard is somewhat cumbersome, as this assignment can only be made after the shipment has been posted. To simplify this, **DYCE Feature Suite for Subscription Billing** offers the option of making this assignment in advance during the sales process. Specifically, the customer subscription contract is selected in the sales line in the new field **Add to Customer Subscription Contract**. In addition to the creation of the subscription, the associated subscription lines in the specified customer subscription contract are retrieved during shipment. ## Assigning bundles {#assigning-bundles} A bundle is always assigned to a customer subscription contract as a whole. Selecting, changing or clearing **Add to Customer Subscription Contract** on the bundle line or on any of its components applies the same value to all lines of the bundle. If the bundle is set up to [adjust quantities by usage data](/docs/fssb/usage-data-bundles.md), this setting is carried over to the bundle in the customer subscription contract. ## Restrictions It is generally not possible to select an *inactive* customer subscription contract. Nevertheless, it can happen that a contract is changed to *inactive* after selection (e.g. by another user). In this case, the shipment is posted, but the subscription lines are not assigned to the contract. The user also receives a corresponding message. The system behaves in a similar way if the **Sell-to to Customer** or the **Currency** differs in the customer subscription contract. In both cases, the shipment is also posted, but the subscription lines are not assigned to the contract. The user also receives a corresponding message here. --- ## Setup(Fssb) # Setup of DYCE Feature Suite for Subscription Billing **DYCE Feature Suite for Subscription Billing** does not require any specific setup. ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCEFEATURESUITESB-READ (DYCE Feature Suite for Subscription Billing READ)** This permission set contains read permissions for the linked apps. It can generally be assigned to all users. * **DYCEFEATURESUITESB-EDIT (DYCE Feature Suite for Subscription Billing EDIT)** This permission set contains permissions to write and change data sets for the linked apps. * **DYCEFEATURESUITESB-ADMIN (DYCE Feature Suite for Subscription Billing ADMIN)** This permission set contains admin permissions for the linked apps. The permission sets build on each other and contain the respective underlying set. As the app does not contain any tables of its own, all three sets are empty at first glance, but have connections to permission sets of the linked apps. They can therefore be used to easily assign permissions to the linked apps. For more information on permission sets, see this part of the Microsoft documentation. --- ## Tiered pricing With **DYCE Feature Suite for Subscription Billing** two types of tiered pricing are supported: *flat* and *true* tiered pricing. Both are maintained via sales price lists. Therefore, *New sales pricing experience* must be activated in **Feature Management**. The actual definition is made via two additional options in the **Defined** field. If one of the options is selected, the **Amount for Price Tier** can be defined for the tier. If *Flat-Tier pricing* is selected, the quantity scales are created based on the minimum quantities with a total price for the tier. For *True-Tier pricing*, each tier has its own price. All relevant price scales are taken into account for the price determination and the sum of the tier amounts then results in the tier price. In both cases, the calculated tier price always applies to all quantities within a price tier. As the total price remains the same for different quantities within a price tier, the unit price is calculated in each case and decreases with increasing quantities within a tier. ## Create and maintain tiered pricing To set up tiered pricing for an item, you must use the **Sales Prices** action from the Item card (or list). The action is located in the menu group *Prices and Discounts*. A price tier is defined using the **Minimum Quantity**. In contrast to the Business Central standard, tiered prices do not define the unit price (in combination with a minimum quantity), but the total amount for the price tier. Therefore, when selecting one of the tier price options, the **Unit Price** field is not editable but the new **Amount for Price Tier** field is. :::warning Tier prices and non-tier prices Item prices can be defined for different scopes (entities). In the context of price lists, this is done via the **Assign-to Type** field. It specifies the type of entity for which the price list/line is valid. For example, prices can be defined for *All Customers*, *Customer Price Groups* or for a specific *Customer*. However, it is *not* possible to mix tier prices and *non*-tier prices within one area of validity. ::: :::info Tier prices and discounts The use of tier prices conflicts with the use of discounts. For this reason, existing discounts are removed when tier prices are created. ::: ### Example: Flat-Tier pricing Excelsis Software Solutions is planning to introduce package prices for different user levels for its software product. A package for up to 20 users costs 159 EUR per month. The next tier is the package for up to 30 users for EUR 229. This means that a customer with 21 users makes a one-time jump from 159 EUR to 229 EUR. All units are charged at the price of the applicable price tier. The following lines are configured for an item in the price list: * Line 1: Minimum quantity = 0, amount = 159 * Line 2: Minimum quantity = 21, amount = 229 * Line 3: Minimum quantity = 51, amount = 399 Line 2 is relevant for a quantity of 25, so this amount (229 EUR) is taken as the total price. ### Example: True-Tier pricing Quantum Software plans to introduce package pricing for different user tiers, but with a more detailed approach, i.e. each tier has a specific price that adds up. One tier for up to 10 users costs 99 EUR per month, the next tier for up to 20 users costs 69 EUR and the next tier for up to 30 users costs 49 EUR. This means that a customer with 25 users pays a total price of EUR 217. Each price tier is calculated separately and added together. The following lines are configured for an item in the price list: * Line 1: Minimum quantity = 0, amount = 99 * Line 2: Minimum quantity = 11, amount = 69 * Line 3: Minimum quantity = 21, amount = 49 * Line 4: Minimum quantity = 51, amount = 39 Lines 1-3 are relevant for a quantity of 25. The sum of the amounts of all lines is 217 EUR. This amount is taken as the total price. ## Use of tiered pricing As part of pricing, tier prices are used in the sales line - both for subscription items and for items without a subscription option and in customer subscription contracts. ### Usage-Based Billing {#tier-pricing-usage-data} Tier pricing is also applied during the **Process Usage Data Billing** step. It takes effect only when **Usage Based Pricing** is set to *Usage Quantity* on the subscription line. For all other pricing options, normal pricing continues unchanged. The applicable tier is determined by the quantity imported from the usage data. The pricing logic works the same way as for subscription lines: * **Flat-Tier pricing** — The amount of the matching tier is used as the billing base. * **True-Tier pricing** — The amounts of all qualifying tiers are summed based on the imported quantity. If no tier pricing is configured, normal pricing is applied. After processing, the subscription line price is updated to reflect the calculated tier amount. ## Considering existing subscriptions {#considering-existing-subscriptions} When a customer purchases additional licenses, the quantity from an existing subscription can be taken into account for tier price determination. This ensures that the customer benefits from the correct price tier based on their total quantity — existing plus new. ### Fields on the sales line {#tier-base-fields} Two new fields are available on sales quote and sales order lines: * **Tier Base Quantity** — Specifies the quantity used as the basis for calculating tiered pricing. This value can be filled automatically from the subscription or entered manually. The field is displayed to the left of **Quantity** to indicate the relationship between the two values. Negative values are not allowed. * **Tier Base Subscription No.** — Stores the subscription that is taken into account when calculating the tiered prices and updated with the shipment. This field is not visible and is only filled by the system. :::note Copy and archive behavior Both fields are **not** copied when using *Copy Document* and are not archived. However, when a sales quote is converted to a sales order, both field values are transferred to the order line. ::: ### Selecting a subscription {#select-subscription} Use the **Select Subscription Qty.** action in the *Manage* menu of the sales quote or sales order lines to populate **Tier Base Quantity** from an existing subscription. The action opens a list of subscriptions belonging to the same sell-to customer and matching the sales line's item. After confirming the selection, the subscription's quantity is transferred to **Tier Base Quantity** and the subscription number is stored internally. The following conditions must be met for a subscription to be selectable: * The item in the sales line and in the subscription must match. * A subscription item must already be set in the sales line. * All open subscription lines must have a calculation basis of 100%. * All sales subscription lines must have a calculation basis of 100%. * All customer and vendor subscription lines must be assigned to the same customer or vendor subscription contract (or to no contract at all). Once a subscription has been selected, **Tier Base Quantity** can no longer be changed manually. To remove the subscription assignment, delete the line and re-enter it. ### Pricing behavior {#tier-base-pricing} When **Quantity** is set, both **Quantity** and **Tier Base Quantity** are used together to determine the applicable price tier. Clearing **Tier Base Quantity** re-triggers price determination. This only applies to tier-priced items — for items without tier pricing, only **Quantity** is taken into account. If a subscription is selected, the unit price shown in the sales line reflects only the delta the customer is charged for: the total amount of the existing subscription lines is subtracted from the line amount and the unit price is recalculated accordingly. If both quantities are set but no subscription is selected, the subscription is created with the sum of both quantities on posting, while only the actual **Quantity** is invoiced. ### Subscription update on shipment {#tier-base-shipment} When the sales order is posted and a subscription was selected, the subscription is updated automatically: 1. All open lines of the selected subscription are closed — the **Subscription Line End Date** is set to the shipment date or to *Next Billing Date* minus one day, whichever is later. 2. The subscription quantity is updated to the new total and new subscription lines with the new tier price are created. :::warning Billing lines block posting If at least one billing line exists for the selected subscription, posting is blocked. Process or delete the billing line before posting the sales order. ::: --- ## Usage data bundles When a [bundle](/docs/ebs/bundles.md) contains a usage-based component, a change in its quantity can be applied automatically to all other components of the bundle. This keeps the components of grouped subscriptions (e.g. a third-party license sold together with a proprietary service) in the correct ratio without manual corrections. ## Setup {#setup} The automatic adjustment is enabled per bundle with the **Adjust quantities by usage data** field on the **Bundle** page (function **Edit Bundle**). In sales documents, the field is shown as **Adjust quantities by usage data (contract)**, because the adjustment only takes effect once the bundle is in a customer subscription contract. The setting is carried over to the bundle in the customer subscription contract when the shipment is posted. The field can only be enabled if the bundle meets the following conditions: * The bundle contains at most one component whose customer subscription line has **Usage Based Pricing** = *Usage Quantity*. This component triggers the adjustment. If the bundle contains more than one such component, the field is read-only. * No component of the bundle has a customer subscription line with a different usage-based pricing, such as *Fixed Quantity* or *Unit Cost Surcharge*. These carry no usage quantity the adjustment could follow. While the field is enabled, components that violate these conditions cannot be added to the bundle. ## Adjusting quantities by usage data {#adjusting-quantities} When the quantity of the subscription of the usage-based component changes, for example by processing usage data, the quantities of all other components are changed automatically. Each component keeps the ratio it had to the usage-based component before the change: the difference in quantity is multiplied by this ratio and added to the component's quantity. The bundle quantity changes by the same ratio as the usage-based component. Example: the quantity of the usage-based component changes from 5 to 8. |Component|Ratio|Quantity before|Quantity after| |:--|:--|--:|--:| |Usage-based component| |5|8| |Component A|1:1|5|8| |Component B|1:2|10|16| If the quantity of the usage-based component was 0 before the change, there is no ratio to apply. In this case, the difference in quantity is added to every other component unchanged and the bundle quantity remains as it is. Changing the quantity of any *other* component does not affect the rest of the bundle. It defines a new ratio for that component instead. Vendor subscription lines are not adjusted separately. They follow the quantity of their subscription as in Business Central standard. ## Bundles without adjustment by usage data {#without-adjustment} If **Adjust quantities by usage data** is not enabled, quantities in a customer subscription contract behave as follows: * Changing the bundle quantity in the contract line changes the quantities of all components by the same ratio. * Changing the quantity of a single component changes only that component. A notification prompts to review the other components of the bundle and to adjust their quantities if required. ## Assigning bundles to contracts {#assigning-bundles} A bundle is always assigned to a customer subscription contract as a whole. See [Preassigning contracts](/docs/fssb/preassigning-contracts.md#assigning-bundles) for details. --- ## Billing In principle, all usage data per contract line or Service Commitments are added together when billing. They form the basis for billing. Contract lines whose Service Commitments are marked as **Usage Based Billing**=*YES*, but for which no usage data is available, are accordingly not taken into account when invoicing. ## Generate Purchase invoices After the usage data has been imported and processed via the **Usage Data Imports** page, the invoicing towards the supplier can be started in the same page. The **Create Purchase Invoices** action (via *Process*) will create one or more Purchase invoices for the supplier based on the usage data from the current import. Whether this results in one or more Purchase invoices is controlled by the selection in the **Vendor Invoice per** field at the Supplier. When *Import* is selected, only one document (possibly a collective invoice for several Vendor Contracts) is created. If *End Customer* option is selected, one Vendor Contract invoice will be created for each related Customer Contract. Thereby - analogous to the [creation of a contract invoice](/docs/srb/working-with-contracts/vendor-contracts.md#create-invoice-per-contract) - first billing lines are created in the background, for which the [posting document](/docs/srb/posting-documents.md) is created immediately afterwards. When this document is deleted, the billing lines are also deleted immediately. :::info Note The Vendor Contract invoice(s) should exactly match the usage data previously imported. For this reason, only those contract lines for which usage data is available in the import will be considered. ::: The unposted Vendor Contract invoice(s) generated in the transaction can then be accessed and further processed or posted via the **Vendor Contract Invoices** action (via *Related / Usage Based Billing*). In addition, the invoice can also be viewed at the respective Vendor Contract and **Usage Data Billing** (via the **Document Type** and **Document No.** fields). ## Generate Sales invoices Customer usage data can also be billed to the Customer after processing via the **Usage Data Imports** page. The **Create Sales Invoices** action (via *Process*) creates one Contract invoice per Customer Contract based on the usage data of the current import. Thereby - analogous to the [creation of a contract invoice](/docs/srb/working-with-contracts/customer-contracts.md#create-invoice-per-contract) - first billing lines are created in the background, for which the [posting document](/docs/srb/posting-documents.md) is created immediately afterwards. When this document is deleted, the billing lines are also deleted immediately. :::info Pause Billing If no usage data is available for a billing period, this period will not be taken into account during billing. The next time usage data is billed, this pause will be skipped. ::: The unposted Customer Contract invoice(s) generated during the process can subsequently be accessed and further processed or posted via the **Customer Contract Invoices** action (via *Related / Usage Based Billing*). In addition, the invoice can also be viewed at the respective Customer Contract and **Usage Data Billing** (via the **Document Type** and **Document No.** fields). :::warning Note When creating Customer Contract invoices, only those contract lines are considered for which usage data is available in the import. ::: ## Recurring Billing As an alternative to the above way of creating contract invoices via the **Usage Data Imports** page, the two previous ways (via **DYCE Subscription & Recurring Billing**) are also available. On the one hand, a separate invoice can be created per contract using the **Create Contract Invoice** action (via *Process* in the respective Contract cards). On the other hand the [Recurring Billing](/docs/srb/recurring-billing.md) (incl. all known functions like filter e.g. on [Contract Types](/docs/srb/setup/contract-types.md) and [Billing Templates](/srb/recurring-billing.md#billing-templates)) can be used. In addition, usage data for one particular billing line can be accessed or displayed using the **Usage Data** action (via *Navigate*). :::info Credit Memos It can happen that due to usage data in the billing period for a contract a Credit Memo has to be created instead of an invoice. In this case, the system recognizes which Document Type (invoice or credit memo) must be used based on the total amount per document. ::: --- ## Features(Ubb) # Features of DYCE Usage Based Billing ## Master data * Service Commitment Templates and Service Commitment Packages to be used with Usage Based Billing * Suppliers with different import schemes * Integration of Data Exchange Definitions ## Sales * Use of items with usage-based billing in sales documents ## Contract management * Creation of contracts based on usage data * Subsequent linking of transaction data with usage data ## Usage data * Import of usage data from different suppliers * Import via reconciliation files or via web service * Processing suitable for mass data incl. pricing * Daily accurate billing also for quantity changes and partial periods ## Contract billing * Customer pricing based on different criteria * Overview of the Service Commitments to be billed as a Billing Proposal with details * Creation of contract invoices in batches * Detail Overview of the contract invoice with billing details * Credit Memos for Contracts and refunds --- ## First Steps(Ubb) # First steps First, a **Usage Data Supplier** is set up and a matching import schema for related usage data is created via the **Data Exchange Definitions**. This will be linked to the **Usage Data Supplier**. Afterwards, a new **Usage Data Import** is created for the supplier, in which the usage data (in the form of reconciliation files) is imported. The imported data is processed. If an error occurs (e.g. because new usage data not previously known to the system is included in the import), the reasons for the non-processing can be corrected and the processing restarted. The final step is to create the related Contract Invoices. This can be done as a batch processing. ## Graphic illustration ![](/img/ubb/ProcessOverview.png) --- ## Glossary(Ubb) ***Coming soon*** --- ## Customers & Subscriptions In addition to the usage data that changes per import, there is also data that has more the character of master data, since it does not change. This includes both the customers for whom the usage data is imported and the subscriptions on the basis of which the link to the Service Commitments to be billed is established. In the case of the customers, this is supporting but not necessary data, whereas without a subscription, no billing of usage data is possible. ## Usage data customers The **Usage Data Customers** page displays the records of customers for which usage data is provided for processing. At the [supplier](/docs/ubb/masterdata/suppliers.md), the **Create customers** field can be used to set whether an entry should be created automatically in this overview when usage data is imported ([see below](#create-customers-based-on-usage-data)). Since these entries are based on usage data and thus represent the supplier's data, they may differ from the master data in Business Central. Therefore, a link can be created based on the Customer. This data is not required for processing and billing of usage data. The page is for clarity reasons only. Records are identified by the **Supplier No.** field to which supplier they belong. Via the **Customer No.** a link to the master data can be established. **Usage Data Customers** not yet linked to a Customer will be displayed in blue-green to indicate that the assignment has not yet been made. For the entries colored in black, the link has already been made. The **Supplier Reference** field contains the unique ID of the customer at the supplier. This value contains a link to the [central references](/docs/ubb/masterdata/references.md) (type=*Customer*) that is automatically created when usage data is processed. ### Create customers based on usage data If it is specified at the supplier that the customers belonging to the usage data are to be created ([see above](#usage-data-customers)), the information from the usage data is used as far as possible to create the data records: * Supplier No. * Supplier description * Customer ID as supplier reference ## Usage data subscriptions The **Usage Data Subscriptions** page displays the subscriptions that belong to the usage data to be processed. On the [supplier](/docs/ubb/masterdata/suppliers.md), the **Create Subscriptions** field can be used to set whether an entry should be created automatically in this overview when usage data is imported or during its processing ([see below](#create-subscriptions-based-on-usage-data)). These entries represent the supplier's data regarding the customer's subscriptions. For processing and billing usage data this data is *required*. If the data is not created via the above-mentioned indicator at the supplier in advance or during the processing of usage data, this must therefore be done manually or by another means. It is therefore recommended to let the system create the **Usage Data Subscriptions** via this way. In addition, this page serves general clarity. The records are identified by **Supplier No.** to which supplier they belong. Via the functionalities **[Extend Contract](/docs/ubb/processing-usage-data/extend-contract.md)** and **[Connect Subscription with Service Object](/docs/ubb/processing-usage-data/connect-subscription-service-object.md)** links to the Customer (**Customer No.**) and to the related [Service Object](/docs/srb/working-with-contracts/service-objects.md) are established. Subscriptions not yet associated with a Service Object are shown colored blue-green to indicate that the association has not yet been made. For the entries colored in black, the linking has already been done. The **Supplier Reference** field contains the unique ID of the subscription at the supplier. This value contains a link to the [central references](/docs/ubb/masterdata/references.md) (type=*Subscription*) that is automatically created when usage data is processed. ### Create subscriptions based on usage data If it is specified at the supplier that the subscriptions belonging to the usage data are to be created ([see above](#usage-data-subscriptions)), the information from the usage data is used as far as possible to create the data records: * Supplier No. * Customer ID * Supplier reference (as ID of the subscription) * Subscription Name * Subscription Description * Subscription Start Date * Subscription End Date * Product ID * Product Name * Unit of Measure * Quantity --- ## Data Exchange Definitions This is a standard functionality of Business Central, which is explained in this part of the Microsoft documentation. However, since it is fundamental to the import and subsequent processing of usage data, at least the aspects relevant to **DYCE Usage Base Billing** will be summarized again here. :::info Example The Data Exchange Definition described here as an example refers to an import file for usage data, which is a CSV file in UTF-8 encoding with column separators as semicolons. However, the Data Exchange Definitions provide much more functionality beyond that, such as exporting data. ::: ## Definition for data import For later billing usage data must first be [imported](/docs/ubb/processing-usage-data/imports-processing.md#process-import-usage-data) and then [processed](/docs/ubb/processing-usage-data/imports-processing.md#process-process-usage-data). In order for the system to properly extract the data from the reconciliation file, it needs a schema of exactly how the data exists. This schema is stored at the [usage data supplier](/docs/ubb/masterdata/suppliers.md#settings-on-the-supplier). :::note Note With the installation of **DYCE Usage Based Billing** the Data Exchange Definition *DYCE-UBB* is delivered as a sample. However, this must be adapted to your own circumstances. Data Exchange Definitions can be exported and imported via the respective actions. ::: The Data Exchange Definitions can be called up via the menu or the search (*Alt+Q*). The page consists of three parts: * **General** In this part, settings are made that affect the import file itself. The most important fields are: * **File Type** For the import of usage data, *Variable Text* is usually selected here. * **Type** For the import of usage data, *Generic Import* is usually selected here. * **File Encoding** The encoding of unicode characters for the import file is selected here. * **Column Separator** This specifies the separator character used to separate the columns in the import file. This is only relevant for the *Variable Text* file type. * **Header Lines** This sets how many header lines the import file contains. This ensures that the header data is not imported. * **Column Definitions** Inexperienced users of Data Exchange Definitions may find it confusing that this fast tab is displayed *at the bottom* of the page, as this must be filled *prior* to the related line definitions. This is where the columns to be imported are defined: * The **Column No.** field specifies the number of the column in the import file. * The **Name** field specifies the name of the column. For reasons of clarity, it is advisable to use the same name as in the header of the import file. * The **Data Type** specifies whether the data to be imported is of type *Text*, *Date* or *Decimal*. * The **Data Format** refers primarily to data of type=*Date*. The formatting of the date in the associated field is specified here. For a date in US format, the value *MM-DD-YYYY* must be specified here. * In the field **Data Formatting Culture** the culture of the data format is specified, if necessary. For example, *en-US* for the data type *decimal* indicates that the period is used as decimal separator according to US format. * The field **Length** is only relevant if the file type is set to *Fixed Text*. * The remaining fields are not required for the import described here. * **Line Definitions** In this fast tab only one line has to be defined, so that afterwards the mapping between the columns of the import file and the fields of the target table can be done via the **Field Mapping**. As **Line Type** *Detail* is selected, a unique **Code** and a **Description** are assigned and the number of columns to be processed (imported) is specified in **Column Count**. The automatically created line of **Line Type**=*Header* is deleted. Subsequently, the following settings must be made via the **Field Mapping** action: * First, a new mapping must be created via the *PLUS* icon. * As **Table ID** the number *70921110* is entered. This is the *Imported Lines* for the *Generic* import type. * In the field **Name** a speaking name should be assigned. * The number *70921104* is entered as the **Mapping Codeunit**. The codeunit will be used for the *Generic* import type when generating the *Imported Lines*. * In the **Column No.** field, a column specified via the *Column Definitions* can be selected and assigned to a target field via the **Field ID** (in the table specified in **Table ID**). * The **Overwrite Value** field indicates that field contents in the target table can be overwritten if necessary. It is recommended that this be set for the *Subscription ID*, *Product ID*, *Product Name*, and *Quantity* fields. * The remaining fields are not required for the import described here. --- ## References # Usage data supplier references In order for usage data to be processed and billed at all, the system must find all additional data required for this purpose. First of all, this includes the [Subscription](/docs/ubb/masterdata/customers-subscriptions.md), which in turn is linked to a [Service Commitment](/docs/ubb/masterdata/service-commitments.md#service-commitment-packages), which is part of a Vendor or Customer Contract. :::info Only Service Commitments that are part of a Vendor or Customer Contract can be charged. ::: The usage data usually only *knows* the subscription to which it is related. The Service Commitments, on the other hand, *know* to which contract they are assigned. The link is the Subscriptions, whose connection to a Service Commitment must be known to the system. In detail, this is implemented in such a way that for each Subscription or its ID, an entry is created in **Usage Data Supplier References**. The unique number of this entry is entered in the Service Commitments. Via this path, the usage data finds the related Subscription, the Service Commitments, the Service Objects and their items. The items are required for pricing, depending on the [method for pricing](/docs/ubb/masterdata/service-commitments.md#service-commitment-packages), and in turn go into the [Usage Data Billing](/docs/ubb/processing-usage-data/imports-processing.md). Vendor and Customer Contracts are then used to bill for usage data. ## References for subscriptions To ensure the uniqueness of subscriptions, each subscription or its ID has an entry in **Usage Data Supplier References**. This reference always belongs to the supplier that is used to import the usage data for a subscription. In case of [automatic creation of a subscription](/docs/ubb/masterdata/customers-subscriptions.md#usage-data-subscriptions) the record is also created automatically. Otherwise, the reference must be created manually. To maintain the subscription reference, the reference table can be called either via the field **Supplier Reference Entry No.** (may have to be shown if needed) in the [Usage Data Subscriptions](/docs/ubb/masterdata/customers-subscriptions.md#usage-data-subscriptions) or via the menu or search (*Alt+Q*). A reference for a subscription appears in the **Usage Data Supplier References** page as a type of *Subscription*. ## References for products Similar to subscriptions, supplier products can also be linked to the Item master data in DYCE via a unique supplier reference. In the future, this can be done, for example, by importing a supplier price list. However, the link can also be made manually directly in the Item if the subscription's item already exist in the master data (Items). In order to maintain the product reference, a link to a (also manually) entered supplier product reference is created in the relevant Item card via the **Item Vendor Catalog** (call via *Related / Purchases / Vendors* or via the lookup in the **Usage Data Supplier Reference Exists** field in the *Replenishment* fast tab) or via the **Item References** (call via *Related / Item*). This appears in the **Usage Data Supplier References** page as type *Product*. :::info Extend Contract For each item, a separate product reference can be entered per **[Usage Data Supplier](/docs/ubb/masterdata/suppliers.md)**. This is primarily used to allow the system to suggest the appropriate item as part of the **[Extend Contract](/docs/ubb/processing-usage-data/extend-contract.md)** functionality. If the product references are not stored in the item master data, the corresponding item can also be selected manually. ::: ## References for customers To support clarity, a list of customers for which usage data is imported and processed can be created automatically. However, this is optional. Each customer or its ID then also has an entry in **Usage Data Supplier References**. When [automatically creating a customer](/docs/ubb/masterdata/customers-subscriptions.md#usage-data-customers), the record is also created automatically. Otherwise, the reference must be created manually. To maintain the customer reference, the reference table can be called either via the field **Supplier Reference Entry No.** (may have to be shown if needed) in the [Usage Data Customers](/docs/ubb/masterdata/customers-subscriptions.md#usage-data-customers) or via the menu or search (*Alt+Q*). A reference for a customer appears in the **Usage Data Supplier References** page as type *Customer*. --- ## Service Commitments(Masterdata) # Extension of Service Commitments Since **DYCE Usage Based Billing** is an [extension](/docs/ubb/purpose.md) of **[DYCE Subscription & Recurring Billing](/docs/srb/welcome.md)**, only the differences are discussed here. For more information on Service Commitments and how to set them up, please see [this](/docs/srb/masterdata/service-commitments.md) part of the DYCE documentation. ## Service Commitment Templates Since Service Commitment Templates can be optionally created, the additional fields are explained within the [Service Commitment Packages](#service-commitment-packages). ## Service Commitment Packages Both Service Commitment Templates and Service Commitment Package lines can be used to create defaults that are necessary for subsequent processing of usage data. * Via **Usage Based Billing**, it is specified that the Service Commitments arising from this package line are generally billed based on the underlying usage. This is done in the form of usage data that is [imported and processed](/docs/ubb/processing-usage-data/imports-processing.md). Therefore, the field of the same name in the Service Commitment is used to determine the Service Object. The **Usage Based Pricing** is only relevant on the sales side and is decisive for the subsequent billing towards the customers. On the purchasing side, the (purchase) prices from the usage data are used for the contract invoices on the vendor or supplier side. * The **Usage Based Pricing** field defines how the prices are determined. The following options are available for this purpose: * If **Usage Based Billing** is set, but the **Usage Based Pricing** field is blank, no pricing is determined for the related usage data. * **Usage Quantity** This option is used when the customer is charges for the actual used quantity. This can be per billing period, for example, licenses (software), consumption minutes (car sharing) or the number of transactions. The sales price (per unit) is determined on the basis of the related item, depending on the quantity. * **Fixed Quantity** With this option, the original quantity remains fixed when the usage data is imported. Thus, the Customer will always be charged for the quantity entered in the Service Object. An adjustment of the quantities based on the usage data does not take place. This pricing thus serves the flat-rate billing of Service Commitments, which, however, only takes place if usage data is actually available. * **Unit Cost Surcharge** With the option *Unit Cost Surcharge* the imported consumption quantity is also disregarded. However, the unit cost plus the specified surcharge is passed on to the customer. This option is usually used for consumption-based (or volume-based) billing. In this case, all unit costs belonging to the subscription are added up and the surcharge is then calculated on the total. * **Consumption Quantity** This pricing option also leaves the quantity in the Service Object unaffected. However, there is no aggregation of all usage data to one single Service Commitment (as with the *Unit Cost Surcharge* option). Here, too, the sales price (per unit) is determined on a quantity-dependent basis using the related item. * If you select the *Unit Cost Surcharge* option in the **Usage Based Pricing** field, the percentage value for the surcharge is stored in **Pricing Unit Cost Surcharge %**. For all other options this field is not editable. --- ## Suppliers # Usage data suppliers A **Usage Data Supplier** is the business partner who provides the usage data for subsequent processing. This is usually the provider of the services for subsequent processing. In the page of the same name new suppliers can be created or already created suppliers can be adapted. In addition to a unique, self-assigned **No.** an explanatory **Description** can be entered. The **Vendor Name** can be used to connect to a vendor. This is especially relevant for the [import and processing](/docs/pli/price-list.md#supplier-reference-for-usage-data) of CSP/NCE price lists. In the field **Type** only the selection *Generic* is currently available. This means that the data to be imported is not imported via a specific interface (API). Instead, CSV files can be imported. An API page is also provided as an interface for the generic import. The **Unit Price from Import** field influences the customer pricing of the usage data and specifies whether the sales price from the usage data should be used. If a supplier is flagged this way, pricing based on the Service Commitments will be overridden. In this case, the import file must contain the customer pricing and the related [Data Exchange Definitions](/docs/ubb/masterdata/dataexchangedefinitions.md) ([see below](#settings-on-the-supplier)) must be set to process this information. The **Vendor Invoice per** field specifies whether vendor invoices are created as a collective invoice per import or as one invoice per customer / end user. ## Settings on the supplier In the **Settings** further connector specific defaults can be made. In addition to the **[Data Exchange Definitions](/docs/ubb/masterdata/dataexchangedefinitions.md)** to be used for the import, the **[Create Customers](/docs/ubb/masterdata/customers-subscriptions.md#usage-data-customers)** and **[Create Subscriptions](/docs/ubb/masterdata/customers-subscriptions.md#usage-data-subscriptions)** fields control whether this data is automatically created during usage data processing. In addition, the **Process without Usage Data Blobs** field indicates that no data from the related blob field is used as the basis for processing the usage data. This is the case, for example, if the usage data is imported via [API](/docs/ubb/processing-usage-data/imports-processing.md#import-usage-data-via-api). If the field is set to *YES*, the first step in usage data processing is skipped. It is not needed in this case or it is a hindrance, because it leads to the Imported Lines being overwritten with *empty* and thus de facto deleted. ### Custom processing of usage data If it is necessary to use custom usage data processing (e.g. because the usage data is only available in a non-standard structure), this can be selected in the **Additional Processing** field, if implemented. Therefore, although the field is hidden by default, it can be shown via *Personalize*. :::note The **Settings** page displays different content depending on **Type**. All other fields in the **Usage Data Supplier** page are generic. ::: --- ## Link subscription subsequently # Linking Subscription with Service Object If an existing Service Object is to be subsequently connected to a Subscription (e.g. if the Service Object was shipped in advance via a Sales Order or created in another way), the **Connect Subscriptions to Service Object** functionality is available for this purpose. The page of the same name shows all Subscriptions that are not yet connected to a Service Object. In addition to the familiar fields from the [Subscriptions overview](/docs/ubb/masterdata/customers-subscriptions.md), the Service Object to be linked can be selected via the **Link to Service Object** field. In the **Connect via** field, the system suggests whether this can be done on the basis of existing Service Commitments or new ones. The basis for this suggestion is whether the existing Service Commitments can be billed on a usage-dependent basis (**Usage Based Billing**=*YES*) and are valid. Via **Connect to Date** the date can be specified for which new Service Commitments are to be created. After setting the defaults, the Subscriptions to be processed are selected and then the action **Connect Subscriptions to Service Object** is called. If errors occur, they will be displayed in the **Reason** field. To correct the cause of the error, the processing status must first be reset using the separate **Reset Processing Status** action. After the error has been corrected, the Subscription can be reconnected. :::warning New Service Objects It is not possible to create new Service Objects using the method described here. If this is desired, the functionality **[Extend Contract](/docs/ubb/processing-usage-data/extend-contract.md)** can be used for this purpose. ::: --- ## Extend Contract # Extend contract To be able to extend a contract quickly and easily, the action **Extend Contract** is available. The basic functionality is explained in [this](/docs/srb/working-with-contracts/customer-contracts.md#extend-contract) part of the DYCE documentation. Therefore, only the differences or the extensions are discussed here. ## Extending a contract based on a subscription In addition to the existing calls via the menu and the Customer Contract, the action is also available in the **Usage Data Subscriptions** and **Imported Lines** pages (lookup in the field of the same name on the **Usage Data Imports** page). This is particularly useful if errors occur during the processing of Imported Lines due to Service Commitments and Service Objects that do not yet exist. Additionally, the extension field **Subscription** can be found in the page in the *Vendor* area. When the page is called up via the **Usage Data Subscriptions** or **Imported Lines**, the Subscription is automatically predefined. When calling up the page via the menu, the Subscription can be selected via the AssistEdit. The **Quantity** and **Provision Start Date** fields are predefined based on the Subscription. The item will also be preselected if it is found via the [product reference](/docs/ubb/masterdata/references.md#references-for-products). If not, it can also be selected manually. :::note Unique product reference missing in usage data If the unique product reference is missing or incomplete in the usage data, the item to be used for the contract extension cannot be suggested by the system. Currently, this is the case in the Microsoft reconciliation file (CSV). This therefore affects Microsoft Tier 1 partners. ::: If the contract extension is executed, the created Service Commitments will automatically receive a link to the [Subscription reference](/docs/ubb/masterdata/references.md#references-for-subscriptions) based on which the future usage data can be found and processed. :::info Rounding of the quantity Since the quantity in the usage data can have any decimal places, but quantities in the Service Object can only be stored with a limited number of decimal places, (commercial) rounding takes place when the field is preassigned. ::: --- ## Imports and Processing # Imports and processing This section explains the import and processing of usage data. It also discusses the different [methods for pricing](#methods-for-pricing) of usage data. ## Usage data imports The first step is to create a new import for the corresponding supplier and import the usage data file. To do this, navigate to the **[Usage Data Suppliers](/docs/ubb/masterdata/suppliers.md)** page and then open the related **Usage Data Imports** using the action of the same name. A new import is created via the **New Import** action. In addition to the data generated by the system, an (individual) description per import can be entered in the **Description** field. Furthermore, the current processing status can be read using the fields **Processing Step**, **Processing Status** and - in case of error - **Reason (Preview)**. The progress of processing can be viewed via this page. [Invoicing](/docs/ubb/billing.md) takes place after the usage data has been processed. ### Structure of the page Usage Data Imports The page has the following action areas: * **New** * The **New Import** action is used to prepare a new import. * **Process** * **Import file** Opens a file dialog to add the import file to the selected import. * **Process Data** Processes the imported usage data, but without creating the invoices. The individual steps *Create Imported Lines*, *Process Imported Lines*, *Create Usage Data Billing* and *Process Usage Data Billing* are automatically run one after the other. * **Create Customer Invoices** Creates a Sales Invoice for all contract elements belonging to the selected import. This creates a separate invoice document for each Customer Contract. The generated contract invoices are posted directly if the **Post documents** indicator is set to *YES* in the dialog. * **Create Vendor Invoices** Creates a Purchase Invoice for all contract components belonging to the selected import. This creates a separate invoice document for each Vendor Contract. Since a **Vendor Invoice No.** is required for posting Purchase Invoices, the option to post the generated documents directly is not available here. * **Manual Processing** (via *Related*) As an alternative to automatic processing of usage data via **Process Data**, the individual steps can also be called up separately. * **Create Imported Lines** Generates the usage data as raw data based on the import file. The [Data Exchange Definition](/docs/ubb/masterdata/dataexchangedefinitions.md) is used, which is stored at the [Usage Data Supplier](/docs/ubb/masterdata/suppliers.md) (in the *Settings* page). The generated Imported Lines can be opened via the lookup in the **No. of Imported Lines** field. * **Process Imported Lines** When processing the Imported Lines, the system attempts to create a link between the usage data and the Service Commitments or Service Objects. If errors occur during processing, the erroneous data can be opened using the lookup in the **No. of Imported Line Errors** field. After correcting the causes of the errors, the processing step can be executed again. * **Create Usage Data Billing** Generates the data needed for actual billing based on the Imported Lines. Since usage data is often vendor or supplier data, this step - depending on the configuration - generates the data needed for customer billing. * **Process Usage Data Billing** In this step, the pricing for the usage data takes place. The respective [method for pricing](#methods-for-pricing) and the period to be billed are taken into account. If errors occur during processing, the incorrect data can be opened via the lookup in the **No. of Usage Data Billing Errors** field. After correcting the causes of the errors, the processing step can be executed again. * **Remove Usage Data Lines & Billing** This action can be used to delete the usage data generated on the basis of the import file and then generate it again. This is useful, for example, if errors occur during processing that can be solved by changing the [Data Exchange Definition](/docs/ubb/masterdata/dataexchangedefinitions.md) used. * **Usage Data Billing** (via *Related*) * **Customer Contracts** This action opens an overview of the Customer Contracts belonging to the import. * **Customer Contract Invoices** This action opens an overview of the Customer Contract Invoices created for the import, but not yet posted. * **Posted Customer Contract Invoices** This action opens an overview of the Customer Contract Invoices created and posted for the import. * **Vendor Contracts** This action opens an overview of the Vendor Contracts associated with the import. * **Vendor Contract Invoices** This action opens an overview of the Vendor Contract Invoices created for the import, but not yet posted. * **Posted Vendor Contract Invoices** This action opens an overview of the Vendor Contract Invoices created and posted for the import. :::info Imported Lines and Usage Data Billing **Imported Lines** The **Usage Data Generic Import** page displays the raw data generated from the import file(s). This usually includes supplier information about the customers, the subscriptions and the respective billing period. The fields **Unit Cost** and **Cost Amount** offer the possibility to import unit prices as well as total prices. If the total price is available in the **Cost Amount** field, the **Unit Cost** is calculated based on the quantity. If the total price is *not* available, it will be calculated based on the quantity and the **Unit Cost**. The page can be opened using the lookup in the field **No. of Imported Lines**. The processing steps are explained in more detail in [Process: Import usage data](#process-import-usage-data). **Usage Data Billing** This page contains the data that serves as the basis for subsequent billing. Depending on how the Services Commitments are set up, related customer usage data is generated for each Vendor usage data. In addition, customer pricing and the updating of prices in the Service Commitments takes place here in the last processing step. Customer pricing depends on the setting in the field **[Unit Price from Import](/docs/ubb/masterdata/suppliers.md)** at the supplier. The page can be opened using the lookup in the field **No. of Usage Data Billing**. The processing steps are explained in more detail in [Process: Process usage data](#process-process-usage-data). ::: ### Import usage data via API In addition to importing usage data via file, import via API (using an API page) is also available. When the page is called up, a new import number is automatically assigned. This number is then used for each transferred data record and is used to assign the data records to an import. Authentication (Service-to-Service, S2S) must be performed when calling the API page. For setup, please refer to this part of the Microsoft documentation. In summary, you need to create an Azure AD application, enter it into Business Central, and assign appropriate access rights (just as you would for users). The page contains further down a nice explanation of the procedure to test the newly set up authentication and web service. The link for calling the page externally is as follows: ```html https://api.businesscentral.dynamics.com/v2.0///api/singhammerITConsulting/dyce/v1.0/companies()/usageDataImports?$expand=usageDataGenericImports ``` * tenant_id = *from the customer system* * environment_name = *from the customer system* * company_id = *from the customer's system* For more details on API pages and their activation, please refer to the Microsoft documentation. :::tip If usage data is imported via API, the **[Process without Usage Data Blobs](/docs/ubb/masterdata/suppliers.md#settings-on-the-supplier)** field should be set to *YES* in the supplier settings. ::: ## Methods for pricing On the purchasing side, i.e. for **Usage Data Billing** with **Partner**=*Vendor*, the prices provided via the supplier are further used, as the supplier usually also provides an invoice for this that matches the usage data. Since with the vendor-side [invoicing](/docs/ubb/billing.md) in the further process a Vendor Contract Invoice is created, this must likewise fit to the usage data and thus also to supplier invoice. The Customer price calculation, on the other hand, depends mainly on two things: * the value in the **Usage Based Pricing** field of the [Service Commitments](/docs/ubb/masterdata/service-commitments.md) belonging to the usage data and * the setting of the **Unit Price from Import** field at the [Usage Data Supplier](/docs/ubb/masterdata/suppliers.md). If the indicator in the **Unit Price from Import** field is *set* at the supplier, the import file must contain this data. In addition, the [Data Exchange Definition](/docs/ubb/masterdata/dataexchangedefinitions.md) must take this information into account. In this case, price calculation does not take place because the supplier of the usage data includes the sales prices and this flag overrides price calculation. During processing, the total amount (for the customer) is divided by the quantity to calculate the unit price. If the indicator is *not* set at the supplier, one of the following methods for customer pricing is used. ### Usage Quantity The price is calculated based on the quantity contained in the usage data. First, the Service Commitments are used to find the Service Object and thus the related item. If necessary, the appropriate price scale is determined via the quantity. The decisive factor here is the contract partner (which is stored in the **Sell-to Customer No.** field of the Customer Contract), not the invoice recipient. Based on the period to be billed (fields **Charge Start Date** and **Charge End Date**), the partial period is calculated to the day (with a corresponding daily price) in the case of a pro-rata billing period. ### Fixed Quantity When processing usage data, the original quantity remains fixed. This means that the customer is always charged the original fixed quantity. There is no adjustment of quantities based on usage data. This pricing thus serves the flat-rate billing of Service Commitments, which, however, only takes place if usage data is actually available. ### Unit Cost Surcharge Here, the imported usage quantity is also disregarded. However, the cost price plus the surcharge specified in the Service Commitments is charged to the customer. This option is often used for consumption-based billing. In this case, all individual prices of the usage data belonging to a subscription are aggregated and then the surcharge is calculated on the total. ### Consumed Quantity This pricing option also leaves the quantity in the Service Object unaffected. However, there is no aggregation of all usage data to one single Service Commitment (as with the *Unit Cost Surcharge* option). It is therefore a combination of the two pricing methods mentioned before. Similarly, the sales price (per unit) is also determined here on a quantity-dependent basis using the related item (via the Service Commitment and the Service Object) and the contract partner (**Sell-to Customer No.** field) in the Customer Contract. ### Pricing for partial periods In addition to the above methods, any partial periods are also taken into account when determining prices. First of all, the following notes apply: * Partial periods exist if the time span between **Charge Start Date** + Dateformula from **Billing Base Period** of the Service is different from the time span between **Charge Start Date** and (inclusive) **Charge End Date**. This can be the case, for example, if there are one or more quantity changes within a billing period or if it is just not a complete billing period. * Since the months have different numbers of days, the month in which the **Charge Start Date** (in **Usage Data Billing**) lies determines which daily price is used as the basis for calculating the partial period (see below). * Provided that it is a full billing period, it is irrelevant whether the billing period is congruent with a calendar month or overlapping. Usage data describing a change in quantity within a billing period usually contains several data records, with the periods matching the corresponding quantity in each case. When calculating prices for partial periods, the system calculates with the respective valid *day price*. For this purpose, first the number of days of the **Calculation Base Period** (from the Service Commitments) is determined, in which the **Charge Start Date** lies. The (billing period) price is then multiplied - taking into account the quantity scale, if applicable - based on the ratio of the two time periods. For the common billing period of 1 month (**Billing Base Period**=*1M*), the daily prices within a calendar month are always identical. Consequently, for two partial periods whose **Charge Start Date** is in two calendar months with different number of days, the daily price is also different. :::warning Different daily prices If the monthly price is the same, the daily price in a month with 31 days (e.g. January) is *lower* than in a month with only 28 days (e.g. February). However, this only applies if it is a partial period. The price of full billing periods, however, is always identical. For a partial period that extends over several months with different numbers of days, the daily price of the respective month always applies. This ensures that for several partial periods within a month, the sum of the daily prices always corresponds to the monthly amount. ::: :::note Examples partial periods **Partial periods within a calendar month** |Charge Start Date|Charge End Date|Number of days|Unit price month|Quantity|Price partial period| |:--|:--|:--|:--|:--|:--| |01.05.2022|10.05.2022|10|35|2|22,58| |11.05.2022|31.05.2022|21|35|5|118,55| Total price for billing period: **141,13** **Overlapping partial periods** |Charge Start Date|Charge End Date|Number of days|Unit price month|Quantity|Price partial period| |:--|:--|:--|:--|:--|:--| |11.01.2022|02.02.2022|23|35|5|138,55| |03.02.2022|10.02.2022|8|35|8|80| Total price for billing period: **218,55** *Note: The amount for the first subperiod is made up of the daily rates for 21 days in January (21/31 * 35 * 5 = 118,55) and 2 days in February (2/28 * 35 * 8 = 20,00)*. ::: ### Billing period from usage data It is quite common but not mandatory that the prices for usage-based Service Commitments are monthly prices. At the same time, there may be differences between the **Billing Base Period** (from Service Commitments) and the actual billed period (from usage data). To take both into account, both periods are compared when calculating the prices (see [Process usage data](#process-process-usage-data)). If they are not identical, the ratio is used as a factor in price calculation. ## Process: Import usage data 1. Via the **[Usage Data Suppliers](/docs/ubb/masterdata/suppliers.md)** page, the related **Usage Data Imports** are opened via the action of the same name. 2. A new import is created via the **New Import** action. The supplier is set automatically. 3. The **Import file** action opens a file dialog with which the import file can be added to the selected import. 4. The file will be stored as a BLOB. The details can be viewed via the lookup in the **No. of Usage Data Blobs** field. Then the [usage data is processed](#process-process-usage-data). ## Process: Process usage data The processing of usage data can be done in just one step via **Process Data**. This comprises several individual steps, which are explained in detail here for better understanding. After importing the reconciliation file, the raw data is generated as individual lines based on the import file via **Create Imported Lines**. The details can be viewed via the lookup in the **Imported Lines** field. 2. When processing the Imported Lines (**Process Imported Lines**), the imported usage data is merged with the Service Commitments and thus Service Objects. [Subscriptions](/docs/ubb/masterdata/customers-subscriptions.md) are used as a link for this purpose, and **DYCE Usage Based Billing** uses them to establish the connection. If required, these records can be created automatically (s. [Settings on the supplier](/docs/ubb/masterdata/suppliers.md#settings-on-the-supplier)). Specifically, the usage data contains the ID of the subscription to which it belongs. Each Subscription, in turn, has a [reference](/docs/ubb/masterdata/references.md) associated with the Service Commitments (via the **Supplier Reference Entry No.** field). When the usage data is merged with the Service Commitments, the validity of the Service Commitments is checked, among other things. If it is not yet or no longer valid, a processing error will be shown. In the event of an error, the affected records can be viewed and corrected via the lookup in the **No. of Imported Line Errors** field. If there is no connection between a Subscription and a Service Commitment, it can be established via the functionality **[Connect Subscription with Service Object](/docs/ubb/processing-usage-data/connect-subscription-service-object.md)**, provided that the Service Commitment and the Service Object already exist. If this is not the case, they can be created using the **[Extend Contract](/docs/ubb/processing-usage-data/extend-contract.md)** functionality and automatically linked in the process. 3. Since usage data is often supplier-side data for which the data required for customer-side billing is (still) missing, customer-side *partner data* is created for each vendor usage data record when generating the **Usage Data Billing** (via **Create Usage Data Billing**) - depending on the configuration (see below) - which is later used for customer-side billing. The details can be viewed via the lookup in the **No. of Usage Data Billing** field. The records in **Usage Data Billing** are *vendor neutral*, meaning all usage data read in is normalized to this table regardless of the original source. 4. When processing **Usage Data Billing** (via **Process Usage Data Billing**), the data in the respective Vendor or Customer Contract lines, in the Service Objects and in the Service Commitments are updated based on the new usage data (quantities and prices). In addition, the sales price is calculated for each data record with **Partner**=*Customer* (see [methods for pricing](#methods-for-pricing)). In case of error, the affected records can be viewed via the lookup in the **No. of Usage Data Billing Errors** field. This step completes the actual processing of the usage data. The next step is the [invoicing](/docs/ubb/billing.md). Ideally, first with the incoming invoice accompanying the usage data of the supplier and then with the further billing in the form of Customer Contract Invoices to the respective customers (although the order is arbitrary). ## Vendor and/or customer usage data In addition to the import of Vendor usage data already described in this section, it is also possible that only Customer usage data is available. This is usually the case when the Service Commitments to be billed are internal services. In such a constellation, both the Service Commitments at the item master data and the Service Commitments at the Service Objects are configured in such a way that there are only Service Commitments with **Partner**=*Customer*. The connection between Subscriptions and Service Commitments is always made via the field **Supplier Reference Entry No.**, whereby a Vendor Service Commitment is always prioritized. However, if there is only one Customer Service Commitment, the connection can also be made via this. When processing usage data, the assignment is therefore made either via the Vendor Service Commitments or, if this is not available, via the Customer Service Commitments. :::info Only customer usage data If only a Customer Service Commitment exists, only those with **Partner**=*Customer* are created when processing the related usage data. ::: --- ## Purpose(Ubb) # Purpose and benefits of DYCE Usage Based Billing **DYCE Usage Based Billing** offers an extremely flexible solution for billing monthly usage data for subscription contracts. The app is constantly evolving to meet ever-increasing requirements. The mass of monthly usage data generated by cloud-based services, for example, is transformed into individual invoices in just a few steps. Unused quantities can automatically lead to Credit Memos. This applies to both Vendor and Customer Contract Invoices. A Detail Overview additionally shows all items individually, if required. Prerequisite for use is the use of **DYCE Subscription & Recurring Billing**. For more information on Contracts, Service Objects and Service Commitments, please refer to [this](/docs/srb/purpose.md) part of the DYCE documentation. ## Usage data If usage data is the basis for billing Service Commitments, it can be imported and processed. Missing data (like Service Objects, Service Commitments and Contracts) can be created within the processing. This step is done only once per subscription. Afterwards, usage data can be processed automatically. The type of usage data can be quite different. The following types are widely used: * Quantity used per period * Transaction volume * Consumption based usage of resources **DYCE Usage Based Billing** can process these different data and further calculate them in different ways. At the same time, it is very likely that the data structure of multiple suppliers is different. ## Billing for usage based Service Commitments Usage data and related Subscriptions are linked to Contracts via Service Commitments. When usage data is processed, price calculation takes place. For Service Commitments on the Vendor side the prices of the Supplier are taken over, for Service Commitments on the Customer side the calculation is done using the corresponding [methods for pricing](/docs/ubb/processing-usage-data/imports-processing.md#methods-for-pricing). The Contracts that include these Service Commitments are then used to generate invoices. --- ## General Setup(Setup) In the **Service Contract Setup** page, general settings and default values for creating and managing Customer and Vendor Contracts (such as number series) are made. ## Usage Based Billing Besides the settings for **DYCE Subscription & Recurring Billing**, no further settings are required for **DYCE Usage Based Billing**. These, however, always refer specifically to a [supplier](/docs/ubb/masterdata/suppliers.md) or a [method](/docs/ubb/masterdata/service-commitments.md) for price calculation. ## Permissions The permissions shipped with **DYCE Usage Based Billing** extend the existing [permission sets](/docs/srb/setup/permissions.md#dyce-subscription--recurring-billing) of **DYCE Subscription & Recurring Billing**: * DYCECONTRACTSALL (DYCE SRB Read) * DYCECONTRACTSUSER (DYCE SRB Edit) * DYCECONTRACTSADMIN (DYCE SRB Admin) --- ## Bundles(Pb) # Bundles and Formatting Bundles can be used in **Sales Quotes** and in **Sales Orders**. They are a combination of individual components into a standalone product. In addition, formatting can be used to control what content and how that content is printed on print documents. Bundles and formatting are part of the **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** app, which is included with **DYCE Project Billing**. ## Use of bundles Bundles can be pre-defined based on [master data](/docs/ebs/bundles.md#master-data-for-bundles) or created [individually (on-the-fly)](/docs/ebs/bundles.md#creating-a-custom-bundle). For more information on creating and using bundles, please refer to [this](/docs/ebs/welcome.md) part of the DYCE documentation. ## Formatting Formatting can be used to control what content and how that content is printed on print documents. This control allows, among other things, the printing of headings and the hiding of components. For more information on formatting, please refer to [this](/docs/ebs/formatting.md) part of the DYCE documentation. --- ## Credit Memos and Cancellation(Pb) # Credit Memos and cancellation Time Recordings that have already been posted cannot be edited. In order to correct a posted Time Recording, it has to be cancelled. In the case of cancelling a Time Recording, a distinction must be made as to whether the related Project Planning Line has already been invoiced. If it has been invoiced, the cancellation can only be performed in the posted Sales Invoice and a Credit Memo must be created. When cancelling, the cancelled budget flows back into the Project Task and, if applicable, the Sales Line. ## Cancellation of unbilled services If an unposted Sales Invoice has been created for the Project Planning Line, it must be deleted before the cancellation is performed. Time Recordings that have not been invoiced can be cancelled in **Project Billing** and via the **Project Planning Line**. A Time Recording cannot be cancelled if the Project Task is in the *Closed* **Status**. ### Call from Project Billing Select the **Project Task** for which the Time Recording was posted. The action *Cancel Service* can be called up in the context menu. Alternatively, the action can be called up in the menu in the *Process* menu item. The action opens the **Cancel Service** page. ### Call from Project Planning Line Select the billable **Project Planning Line** for which the Time Recording has been posted and call the *Cancel Service* action. The action is included in the menu under *More options / Actions / Functions*. It also opens the **Cancel Service** page. :::info Project Task and Project Planning Line for a Time Recording The related Project Task and Project Planning Line are displayed in the Time Recording. ::: ### Service cancellation The page is divided into **Project Planning Lines (Budget)** (top) and **Time Recordings** (bottom). All Time Recordings that are related to a Project Planning Lines will be displayed in bold format when the Project Planning Line is highlighted. From the menu, the **Hide Project Planning Lines** and **Hide Time Recordings** actions can be used to change the view of the page. The **Filter Project Ledger Entries by Project Planning Line (On/Off)** action can be used to filter to the Time Recordings for the selected Project Planning Line. The **Cancel Selected Planning Lines** action cancels the entire Project Planning Line and all related Time Recordings. The **Quantity** in the Project Planning Line is reduced to 0. The link between the **Time Recordings** and the **Project Ledger entries** is released. The **Status** of the Time Recordings is set to *Open*. The **Cancel Selected Time Recordings** action can be used to cancel individually selected Time Recordings. For this purpose, the **Cancel** flag can be set in the *Time Recordings* fast tab. This indicator marks a Time Recording so that it is cancelled with **Cancel Selected Time Recordings**. When **Cancel** is set, the **Quantity to Cancel** is set in the related Project Planning Line. The **Billable Duration** is used in this case for calculating the value. The value cannot be edited in non-billed Project Planning Lines. If in **[Time & Travel Model](/docs/pb/setup/tnt-model.md)** a rounding for the Project Planning Line is stored, this will also be applied when cancelling. If the last Time Recording for a Project Planning Line is cancelled, the complete Project Planning Line will be cancelled. When the **Cancel Selected Time Recordings** action is executed, the quantity in the Project Planning Line is reduced by the **Quantity to Cancel**. The cancelled Time Recordings can be edited again. ## Cancellation of invoiced services Once a service has been invoiced, it or the associated Time Recordings can be cancelled via the posted Sales Invoice. To do this, navigate to the posted Sales Invoice and call **Cancel Service** action in the *Correct* menu item. The **Cancel Service** page will open. When called from the posted Sales Invoice, the page behaves differently in a few ways than when called from the **Project Billing** or Project Planning Line. 1. No **Rounding** When cancelling invoiced Time Recordings, the rounding from the Time and Travel Model is not taken into account. If a Time Recording is marked as to be cancelled, the **Billable Duration** will be added to the **Quantity to Cancel** without rounding. 2. **Quantity to Cancel** editable The cancelled line item will be added to a Credit Memo with the **Quantity to Cancel**. To be able to influence the quantity in the Credit Memo, the **Quantity to Cancel** can be edited. 3. Creating a **Credit Memo** The service or Time Recording has already been invoiced. Accordingly, a Credit Memo must be created. When performing the cancellation, a new Project Planning Line with a negative quantity is automatically created, which is transferred to a Credit Memo. ### Create Credit Memo The Project Planning Line with negative quantity must be posted using a Credit Memo. As long as the Credit Memo is not posted, no further invoice can be issued for the Project Task. The Credit Memo can be created directly in the **Cancel Service** page. For this purpose, a query opens after the cancellation. In this page, the **Posting and Document Date** can be entered for a new Credit Memo or the cancellation can be added to an existing Credit Memo. **Cancel** action does not create a Credit Memo. To subsequently create a Credit Memo, the **Cancel Service** action can be invoked again from the invoice. The action detects the Project Planning Line with negative quantity that does not belong to any document yet and offers to create a Credit Memo again. Alternatively, the **Cancel Service** action can be called directly from the negative Project Planning Line to create a Credit Memo. ## Correct, Cancel and Create Corrective Credit Memo Besides **Cancel Service** the actions [Correct, Cancel and Create Corrective Credit Memo](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-correct-cancel-sales-invoice) can be used to cancel and credit services and time recordings. ### Correct When using the action, the invoice is completely credited and can be invoiced again. However, this is only possible if the Project Tasks status is not *Closed* and the invoice has neither been paid nor already partially credited. The process differs slightly between invoices with and without a reference to a sales order. #### With Sales Order The [functionality](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-how-correct-cancel-sales-invoice) from Dynamics 365 Business Central Standard is retained. All credited items are available in the sales order and can therefore be shipped and invoiced again. Customer Ledger Entries are applied, Project Planning Lines are created, and the Credit Memo will be posted. All services and time recordings are cancelled and can be re-released and posted. #### Without Sales Order The services and time recordings are directly re-posted and transferred to a new unposted sales invoice. :::warning Partial Cancellation If the posted invoice has already been partially cancelled (e.g. via **Cancel Service**), the action **Correct** can no longer be called. ::: ### Cancel If this action is used, the invoice will be credited fully and can be invoiced again. It makes no difference whether the invoice was created with or without a reference to a sales order. All credited items are available in the sales order or Project Task (Project Planning Line) again. They can be shipped and invoiced again. Customer Ledger Entries are applied, Project Planning Lines are created, and the Credit Memo is posted. All services and time recordings have been cancelled and can be re-released and posted. :::warning Partial Cancellation If the posted invoice has already been partially cancelled (e.g. via **Cancel Service**), the action **Cancel** can no longer be called. ::: ### Create Corrective Credit Memo If the posted sales invoice contains one or more services, a dialog will give two options. The user can choose whether a Corrective Credit Memo (no changes) will be created or whether to cancel the services and time recordings. If the services and time Recordings are to be cancelled and credited, the **Cancel Service** page is opened (see above). --- ## Controlling(Pb) ## Dimension Value for Projects In **[Projects Setup](/docs/pb/setup/general.md)**, **Autom. Insert Project Dimension Value** controls whether the **Project No.** is automatically created as a new dimension value for each new project. This is then automatically assigned to the respective Project. If the indicator is subsequently set, a corresponding Dimension Value will also be created for all existing Projects. ## Dimension Value for Customers In the **[Sales & Receivables Setup](/docs/general/essentials/customer-dimension.md)**, **Autom. Insert Customer Dimension Value** controls whether the **Customer No.** is automatically created as a new dimension value for each new Customer. If the indicator is subsequently set, a corresponding Dimension Value will also be created for all existing customers. ## Determine proportional Invoiced Shares If several employees create time recordings for a particular Service, the revenue generated is split between these employees involved. The standard Business Central reports regarding resource statistics have been extended accordingly. When the app is installed, an entry for the 70920904 (Calculate Proportional Invoiced Shares) report is automatically created in the Job Queue. However, this entry must be started manually once in order to have a valid user. A Project Ledger entry consumption is created when a time recording is posted. The report calculates the fields **Proportionately Invoiced Duration (Hours)** and **Proportionately Invoiced Amount** in the Project Ledger entries as long as **Preliminary Invoiced Shares** is set to *YES*. The report sets **Preliminary Invoiced Shares** to *NO*, if the corresponding Project Task has the status *Closed* set. Project Ledger entries with **Preliminarily Invoiced Shares** *NO* are not updated by the report. If the status of the Project Task is set from *Closed* to *Time Recording locked* or *Open*, field **Preliminary Invoiced Shares** is set to *YES* again. The calculation of the proportional duration and amount differs based on the value in **Preliminary Invoiced Shares**. ```math Proportional \ invoiced \ duration = \frac{billable \ duration \ of \ Project \ Ledger \ Entry}{sum \ billable \ duration \ of \ other \ Project \ Ledger \ Entries} * Quantity \ Project \ Planning \ Lines \ Billable \ (in \ hours) ``` Only when the Project Task has the status *Closed* the calculation is carried out using the Project Planning Lines Budget. This results in a final redistribution to all employees who have contributed to the revenue of the Service. As long as the Project Task has the status *Open* or *Time Recordings locked*, the calculation is based on the Project Planning Lines Billable. :::info Service Billing Type Time & Material If the Project Planning Lines has the Service Billing Type **Time & Material**, **Preliminarily Invoiced Shares** is automatically set to *NO*. **Time & Material** is invoiced 1:1. Subsequent redistribution is therefore not necessary. ::: ## Profit and loss accounting (P&L) per project :::warning Disclaimer: Feature in Preview As this feature has not yet been finally evaluated on the basis of productive data, it will be treated as a *Preview* until further notice. This primarily means that it should be carefully tested *before* it is used productively by the customer. ::: Time Recordings can be included in Financial Reports and related costs, imputed sales prices and invoiced shares can be taken into account when evaluating individual projects. By transferring Time Recordings to specific Statistical Accounts, the system enables the creation of a profit and loss statement per project. This facilitates the tracking and analysis of project expenditure, income and profitability and provides users with valuable information on current project expenditure. It builds on the feature to [determine proportional Invoiced Shares](#determine-proportional-invoiced-shares). ### Registration to Statistical Accounts After running the **Calculate Proportional Invoiced Shares** report, a specific series of steps is performed to generate Statistical Accounts Ledger entries in the background. To do this, the system first identifies the last Project Ledger entry that has already been included in the Statistical Accounts Ledger entries. The system then filters the Project Ledger entries using several criteria: * Ledger entries that are newer (larger **Entry No.**) than the last Project Ledger entry in the Statistical Accounts Ledger entries, * **Entry Type** is *Usage*, * **Type** is *Resource*, * **Invoicing Document Type** and **Invoicing No.** are not empty. For each Ledger entry that meets the filter criteria, the system generates three lines in the **Statistical Accounts Journal** stored in the [Projects Setup](/docs/pb/setup/general.md#profit-and-loss-accounting-pl-per-project). Rows are created for each of the columns of the fast tab *[Analysis by Statistical Accounts](/docs/pb/setup/general.md#analysis-by-statistical-accounts)*. These lines are created on the condition that corresponding Statistical Accounts are specified and that the values in the fields **Total Cost**, **Line Amount** and **Proportionally Invoiced Amount** of the Project Ledger entries are greater than zero. Values from different fields of the identified Project Ledger entries are used when creating a Statistical Account Journal line for the *Total Cost*: **Posting Date**, **Document No.**, **Description**, **Dimensions**, and **Entry No.**. The Statistical Account number for this line is determined by the value of the **Service Invoicing Type** field of the Project Ledger entry and the Statistical Account number for *Total Cost* in the fast tab *[Analysis by Statistical Accounts](/docs/pb/setup/general.md#analysis-by-statistical-accounts)*. In addition, the amount is taken from the **Unit Cost (LCY)** field of the corresponding Project Ledger entry. The process for creating Statistical Account Journal lines for the *Total Price* and the *Proportionally Invoiced amount* is similar, but differs in terms of the Statistical Accounts to be used. These are based on the other **Service Invoicing Types** and the setup in the fast tab *[Analysis by Statistical Accounts](/docs/pb/setup/general.md#analysis-by-statistical-accounts)*. The amount is taken from the **Line Amount** or **Proportionally Invoiced Amount** fields of the Project Ledger entries. ### Update If the **Calculate Proportional Invoiced Shares** report is run (manually or automatically via the Job Queue), the Project Ledger entries are updated if necessary (see [determine proportional Invoiced Shares](#determine-proportional-invoiced-shares)). If there are already corresponding Statistical Accounts Ledger entries for a Project Ledger entry, the update of the Project Ledger entry also updates the corresponding Statistical Accounts Ledger entries (using the **Entry No.** and the corresponding Project Ledger entry). ### Using Statistical Accounts in Financial Reports Once the Ledger Entries are registered in the Statistical Accounts, they are available for analysis in Financial Reports. To add a Statistical Account to a Financial Report, go to the **Row Definitions** page of the Financial Reports and select *Statistical Account* in the **Totaling Type** field and a Statistical Account in the **Totaling** field. For more information about including Statistical Accounts in Financial Reports and how to set them up, see this part of the Microsoft documentation. ## Project Ledger Entries - Unit Cost and Unit Price The calculation of the unit price and unit cost for Project Ledger Entries (Usage), created during the posting of time recordings, differs slightly from the standard in Business Central. Since usage relates to the resource in time recording, both unit cost and unit price come from the resource itself. To minimize rounding errors, the unit of measure is always set to **Minutes**. In contrast, Project Ledger Entries (Sales) utilize the unit of measure, unit cost, and unit price from the project planning line (budget). --- ## Features(Pb) # Features of DYCE Project Billing ## Master data * Classification of projects * Responsible salesperson per project * Items for professional services with Service Billing Types (Time & Material, Budget, Fixed Price) * Creation of Bundles (via **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)**) * Configuration of document footers for printing documents (via **[DYCE Essentials](/docs/general/essentials/welcome.md)**) * Role Center for project billing ## Sales * Linking sales documents with projects * Quotes for prospects * Create and budget project tasks * Detailed information in the project tasks * Responsible employee per document / output in reports (via **[DYCE Essentials](/docs/general/essentials/welcome.md)**) * Concurrent calculation of the contribution margin * Details on the billing of services / Detail Overview * Creation of Bundles on-the-fly (via **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)**) * Formatting of sales lines (via **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)**) * DYCE layouts for standard reports support formatting and Bundles (via **[DYCE Essentials](/docs/general/essentials/welcome.md)**) * Project-related purchasing of external resources * Purchase prices per project order / special bid * Position Numbers in sales documents (via **[DYCE Essentials](/docs/general/essentials/welcome.md)**) * Print preview of unposted sales documents (via **[DYCE Essentials](/docs/general/essentials/welcome.md)**) ## Project billing * Overview of services provided for release and posting * Overview of services to be invoiced in orders * Creation of project invoices in a batch (also without order reference) * Cancellation and credit memos of posted project consumptions incl. correction of the order budget * Move Time Recordings between project tasks * Separation of total duration and billable duration (in Time Recordings) ## Time/trip recording and planning * Recording of times on the web (**[DYCE Time Tracking](/docs/web/tt/welcome.md)**) * Worksheet for approval of Time Recordings * Rounding of billable duration * Time Recordings for multiple companies * Archiving of Time Recordings * Planning of projects and resources on the web (**[DYCE Project & Resource Planning](/docs/web/prp/welcome.md)**) ## Evaluation * Automatic dimension per customer (via **[DYCE Essentials](/docs/general/essentials/welcome.md)**) * Automatic dimension per project * Resource Person Defaults (working time, team, cost center) * Budget overview per project * Project controlling also for goods and licenses * Invoiced shares (share of resource in turnover) * Resource and project evaluation (Business Central Standard) --- ## First steps(Pb) With Microsoft Dynamics 365 Business Central 2024 Release Wave 1 (BC24), *Projects* are finally called *Projects* (formerly *Jobs*). ## Role Center In order to find the most important calls for use as quickly and easily as possible, the Role Center **Project Administrator** is available specifically for this purpose. In addition to the master and transaction data, the **[Project Billing](/docs/pb/project-billing.md)** and the history of posted documents can also be called up from here. In addition, the **Time Recordings** to be released and the **Time Recordings** still to be posted are displayed for all Projects in which the user is stored as *Project Manager* (in the field of the same name in the Project Card). The **Purchase Orders required** and **Accruals required** tiles inform the user whether Purchase Orders for external service providers still need to be entered or accruals need to be created for services that have already been invoiced but not yet costed. Via **Help & Support** (the *?* in the upper right corner) [this](/docs/pb/welcome.md) online help can be started. ## Part My Projects With the part *My Projects* the user is given the possibility to save *his* currently active Projects for direct access in a separate table as a favorite. Using the functions in the context menu, it is then possible to navigate quickly and easily to all Project-specific documents and functions within the project management at the click of a button. Clicking on the **Project No.** opens the Project Card. As soon as a *Project Manager* is entered in the field of the same name in the Project Card, the Project automatically appears in the Role Center part of this user. Manual maintenance of this overview is also possible. ## Use of Services and Projects ![](/img/pb/ProcessOverview.png) ## Basic business process The business process for Projects and services can start in **DYCE Project Billing** with the creation of a Sales Opportunity, in the further course of which a Sales Quote can be created. It is possible to already link the quote to a Project. If known, special prices applicable to the Project can also already be entered in the Project. A Project Task to record the presales effort is also already useful at this stage. After the customer has placed the order, further planning of the project components and the resource groups required for this is carried out on the basis of the project plan. Several options are available for an overview of current consumption during the life of a Project. For example, the standard reports of Business Central can be used. In addition, an Account Schedule can be created for the Project evaluation (within Business Central) or evaluations can be provided by an external BI tool. --- ## Glossary(Pb) ***Coming soon*** --- ## Items(Masterdata) # Service Billing Items In addition to retail items, services are also mapped as items in **DYCE Project Billing**. These can be offered and billed via sales documents. People perform these services and report their times for this purpose. Subsequently, **[Project Billing](/docs/pb/project-billing.md)** is used to check and approve these time recordings and finally to invoice the services provided. Service Billing Items are used to provide and sell Services to customers. They describe the actual service, but do not specify which person will actually perform the service. ## Differences in Service Billing Items A Service Billing Item differs from other items in that the **Service Billing Type** field contains a value. It is responsible for how the service will be charged to the customer. The options available for this are *Time & Material*, *Budget* and *Fixed Price*. The field can only be edited for items with **Type**=*Non-Inventory*. The table below explains the differences between the Service Billing Types in detail: |Option|Meaning| |:--|:--| |*EMPTY*|This selection means that this item is *not* used as a Service Billing Item.| |Time & Material|This selection describes a service that is billed to the customer exactly based on the time recordings provided. A deviation of the invoiced quantity compared to the related time recordings is *not* possible. This goes so far that even the quantity in an order line is automatically increased in case of overbooking. |Budget|For items with this Service Billing Type, the quantity to be billed to the customer may differ from the sum of the time recordings. The quantity in a Sales Order line will *not* be automatically increased in case of an overbooking. In **Project Billing**, overbooked budgets are displayed in red so that the user can decide to increase the order quantity (manually) if necessary.| |Fixed Price|This selection behaves similar to *Budget*. Here, however, the deviation of the time recording from the (internal) calculation quantity is the rule rather than the exception. At the same time, for positions with Service Billing Items, this setting can be used to format the print documents so that only "one piece" is ever shown (see info below). A partial invoice for a Fixed Price item is not possible. If this is desired, the **[Payment Plan](/docs/ibt/payment-plan.md)** from **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** can be used for this purpose.| :::info Fixed Price Example The sales department sells a service for 5000 EUR flat. The respective item is entered in the Sales Quote / Order with the quantity based on hours or days calculated for it. In the print documents (independent of the entry in the sales line) shows the quantity 1, the total price and a fixed unit of measure, which can be defined in the **[Sales & Receivables Setup](/docs/pb/setup/general.md)**. Also, no time recording is output on the Detail Overview for the invoice for this position. ::: The **Sales Unit of Measure** provides the possibility to specify a unit of measure different from the base unit of the item, which will be used in the sales transactions for the item. For example, for Service Billing Items, the base unit of measure should always be hours. At the same time, for services that are offered and sold in days, the unit of measure used for days can be specified here. ## Suggestions for naming Service Billing Items A uniform naming scheme contributes to general clarity. The following is therefore a suggestion for such a scheme for Service Billing Items. The first part of the code (two letters) defines the type of service, the second part of the code (three letters) defines the skill, and the third part (two/three letters) defines the billing type. |Code|Description| |:--|:--| |CN-JUN-HRS|Junior Consulting hour| |CN-MAN-HRS|Management Consulting hour| |CN-SEN-HRS|Consulting hour| |CN-DAY|Consulting day| |CO-WU|Coaching work unit| |DEV-WU|Development work unit| |DEV-COA-HR|Development Coach hour| |DEV-JUN-HRS|Junior Development hour| |DEV-SEN-HRS|Development hour| |DEV-DAY|Development day| |PJ-MAN-WU|Project Management work unit| |SU-1ST-HRS|1st-Level Support hour| |TR-EXT-DAY|External Training day| |WS-EXT-DAY|External Workshop day| --- ## Project Tasks and Planning Lines # Project Tasks and Project Planning Lines In **DYCE Project Billing**, Project Tasks are used to record, schedule, record times and invoice all types of services. Project Tasks are needed whenever employees are to record their times. This can be the case for internal (e.g. training, internal meetings, etc.) as well as for external tasks (e.g. workshops, trainings, coachings, etc.). In principle, charging for services can also be handled via normal sales order processing (sales documents). The advantage of processing via Project Tasks and Project Planning Lines is that it is also possible to link the time spent with the services sold. Thus, a direct comparison of the time spent (consumption) to the revenues generated from it is given via the Project Ledger Entries. Project Tasks and Project Planning Lines can either be entered manually or created via a sales order (actions [Create Service Project Tasks](/docs/pb/sales/project-task-planning-lines) and [Manage Project Tasks](/docs/pb/sales/manage-project-tasks) via *Process*). In both cases, a settlement is posted for the customer during invoicing. Project Tasks and Project Planning Lines are often created manually when a service is to be billed quickly to a customer quickly - without any further administrative effort via a sales document. Creating a Project Task including Project Planning Lines is also the best way to record internal (non-billable) services or presales expenses. Further explanation of Project Tasks and Project Planning Lines can be found in [this](/docs/pb/masterdata/project.md#fast-tab-tasks) part of the DYCE documentation. ### Status of Project Tasks Project Tasks can be assigned a **Status**. This primarily refers to the ability to record times for a particular Project Task. The following status options are possible: |Option|Meaning| |:--|:--| |Open|For an open Project Task, times can be recorded, posted and invoiced. A related sales order cannot be deleted. The status is recalculated automatically from **all** of the Project Task's Budget Project Planning Lines whenever one is added, changed or deleted: it becomes (or stays) *Open* as soon as at least one Budget Project Planning Line has a **Service Billing Type** of *Time & Material*, *Budget*, *Fixed Price* or *Additional Service*.| |Time recording locked|Times can no longer be recorded for a Project Task with this status. However, it can still be posted and invoiced. A related sales order cannot be deleted, yet. The status is recalculated the same way as for *Open*: it becomes (or stays) *Time recording locked* once none of the Project Task's Budget Project Planning Lines has a **Service Billing Type** of *Time & Material*, *Budget*, *Fixed Price* or *Additional Service*.| |Closed|For a closed Project Task, times can no longer be recorded, posted or invoiced. A related Sales order can be deleted. This status can only be set if the Project Planning Line Budget is fully invoiced. Project Planning lines Budget are fully invoiced if the quantity of the Project Planning line Billable is equal to the quantity in the associated Project Planning lines Budget and the Project Planning line Billable has been posted via invoices or credit memos. Project Planning Lines billable with quantity 0 do not have to be posted in invoices.| ### Details on Project Planning Lines Project Planning Lines of the type *Budget* are used to map the specifications for the services to be performed. Time recordings always refer to this type of Project Planning Lines. When released time recordings are posted, Project Planning Lines of the type *Billable* are created. These later serve as the basis for invoicing. The link to the corresponding posting document can be seen via the fields **Invoicing Document Type**, **Invoicing Line No.** and **Invoicing Line No.**. During invoicing, Project Ledger Entries are created. There is also a direct link between Project Ledger Entries and Project Planning Lines of type *Billable*. In addition, a Project Planning Line can only ever be linked to exactly one (posted) invoice. :::note Billing of Services In **DYCE Project Billing**, only Service Billing Items are billed directly. Employees or resources of the type *Person* record their times spent on a task and assign them to the corresponding Project Planning Line of the type *Budget*. ::: :::info Time recording For the comfortable recording of times **[DYCE Time Tracking](/docs/web/tt/welcome.md)** is used. The application is described in detail in the corresponding part of the DYCE documentation. ::: --- ## Projects In **DYCE Project Billing** Projects are used to invoice services. In order for services to be provided and invoiced, it is mandatory that at least one Project for each customer is created in Business Central. ## Setting up a new Project To create a new Project, a new Project Card is created, which is filled with all the necessary information for later processing. The easiest way to create a Project is to use the customers or the contacts overview. The **Project** action (in the *New Document* action group) can be used for this purpose. :::info Since each Project can potentially be invoiced, a customer has to be set in the Project. If a Project is to be created via a contact, the contact must be linked to a Customer (via a *Business Relation*). For further explanation of contacts and business relations, see [this](/docs/ibt/customer-contact.md) part of the DYCE documentation (which belongs to **DYCE IT-Business Toolkit**). ::: This way the master data will be automatically transferred to the new Project. Alternatively, a Project can also be created using the **New** action in the lookup of the **Project No.** field in the sales document cards. If a Project is created manually (action **New** in the Project overview), at least the invoice recipient must be explicitly selected. In addition, the existing Projects are visible in the customers and the contacts overview. Via the fact box **Sell-to Sales History** (tile *Projects*) a particular Project or the one just created can be opened directly. In addition, Projects can also be called up either via the Role Center, the navigation menu or via the system-wide search (*Alt+Q*). ## Structure of the Project Card ### Fast tab General When a new Project is created, an empty Project Card is opened first. You should consider using a manual number series for the Project No., since in many places only the **Project No.** field is visible. A *speaking* name instead of a consecutive number can then be advantageous. If the Project Card was created via the customers or contacts overview, the corresponding master data fields are already filled. The following steps are necessary to create a Project: 1. If necessary, select a customer (in the **Bill-to Customer No.** field). 2. Enter a more detailed description of the Project in the **Description** field. 3. Categorize the Project by selecting a **[Project Type](/docs/pb/setup/project-type.md)**. 4. In the field **[Time and Travel Model Code](/docs/pb/setup/tnt-model.md)** a model code for the recording of times for this Project can be stored. This specification is optional. 5. The **Project Manager** can be deposited in the field of the same name via the selection of the users available in the system. From this point on, the Project is automatically displayed in the Role Center part *[My Projects](/docs/pb/first-steps.md)* of this user. 6. In addition, further responsible persons can be entered in the fields **Person Responsible** and **Salesperson Code**. These must have been previously created as a resource or seller with the required information. Both fields are optional entries. 7. The **Base Calendar Code** field determines, depending on the **[Base Calendar Source](/docs/pb/masterdata/surcharges.md#base-calendar-source)** setting in the surcharge model, which calendar is used to identify holidays for surcharge calculation on this project when the **Base Calendar Source** is set to *From Project*. It is pre-filled from the **Company Information** when the project is created and can be changed manually. 8. **Autom. Detail Overview printing** field causes accompanying details to be automatically added to the invoice when billing for Services or printing a corresponding sales invoice for this Project. The Detail Overview contains details of the invoiced Time Recordings and, if applicable, goodwill times. The indicator can already be set up as a default in the customer templates and can also be activated in the customer card. New Projects will then adopt the value from the customer. This can be changed manually there however if necessary. :::info The field **Bill-to Customer No.** can only be set to another customer as long as no further processing or posting has taken place for the Project. ::: ### Fast tab Tasks The lines in the Project Card represent the individual project components (*Project Tasks*). They show both quantities and values or the Project Ledger Entries cumulatively in the respective columns. By clicking on a field, the details can be viewed. With **DYCE Project Billing** Project Tasks can be created both manually or via Sales Orders (actions **Manage Project Tasks**, **Create Service Project Tasks** or **Create other Project Tasks** in *Process*). Project Planning Lines of the type *Budget* are also created at the same time. These are used in the further course to assign Time Recordings and thus form a decisive part for the billing of services. New Project Tasks that have been created via a sales order are compounded based on the order number. For this purpose, additional *Begin-Total* and *End-Total* lines are created for the first Project Task. Further Project Tasks from the same sales order will be sorted accordingly. In the standard version of Business Central, Project Tasks and Planning Lines can only be created manually. However, this would not only be very inconvenient for recording of times, but this would also mean that the project's components would not be linked to the respective budget from the related sales order. ***DYCE Project Billing links these two parts together.*** When Time Recordings are posted, Project Planning Lines of the type *Billable* are automatically created. These are used as the basis for billing the services in the next step. If a Project Task is linked to a Sales Line (e.g. in a Sales Order), the posting of the *Billable* Project Planning Lines is done automatically when invoicing the corresponding Order Line. The description of the Project Tasks and Project Planning Lines generated via the sales order depend on the descriptions used in the order line, which in turn are based by default on the items used. The display of the Project Tasks in the Project Card is used for controlling purposes and, if necessary, for the administration of the individual Project Planning Lines. Further explanations of Project Tasks and Project Planning Lines can be found in [this](/docs/pb/masterdata/project-task-planning-line.md) part of the DYCE documentation. ### Fast tab Posting 1. **Status** field shows the current status of the Project. When a new Project is created, the status is always set to *Open*. However, this can be changed manually. Only open Projects can be posted to. The following status options are possible: |Option|Meaning| |:--|:--| |Planning|The Project is in the planning phase. Posting is not possible in planning status.| |Quote|This status allows you to make preliminary calculations. No posting is possible.| |Open|All Project control functions can be used and changed if necessary. Postings are only possible in this phase. Sales Invoices and Credit Memos can be used to create customer invoices and credit memos for the individual Project Tasks.| |Completed|Completed Projects can no longer be posted. Invoicing is also no longer possible. This step closes the Project. The statistics functions can be used for comparison purposes for completed Projects, or to facilitate planning for future Projects. The actual costs of a completed Project can be compared with the planned amounts. This information is useful not only for comparisons, but also as a guideline or default for future Projects. 2. **Project Posting Group** determines which General Ledger Entries are posted to when batch processing *Post WIP to G/L batch job* is run. WIP is used to reconcile expenses and revenues. The field is copied from **[Projects Setup](/docs/pb/setup/general.md)** when a Project is created. 3. In Business Central, WIP and revenue recognition for sales and expenses can basically be calculated in several ways. The distinction is in the selection of the **WIP Method** for the Project. For more information on WIP methods, please refer to this part of the Microsoft documentation. The field is taken from **[Projects Setup](/docs/pb/setup/general.md)** when a Project is created. 4. **WIP Posting Method** controls whether the WIP method is applied per Project or per Project Ledger Entries. For the *Per Project* selection, WIP is calculated by Business Central using total WIP costs and sales. For *Per Project Ledger Entry*, the summed values for WIP costs and sales are used by Business Central. The field is taken from **[Projects Setup](/docs/pb/setup/general.md)** when a Project is created. 5. The **Allow Budget/Billable Lines** field must always be set to *YES* for Projects in **DYCE Project Billing** to create one Planning Line of type *Budget* and one of type *Billable*. Otherwise, the invoicing of Services is not possible. The field is taken from **[Projects Setup](/docs/pb/setup/general.md)** when a Project is created. 6. **Apply Usage Link** indicates whether Project Ledger Entries of type *Usage* are linked to Project Planning Lines. The link should be activated whenever quantities and amounts of remaining work are to be tracked to view a link between demand planning, consumption and sales. The Usage Link is only used for Project Planning Lines of type *Budget*. This field is usually already predefined with *YES* and should not normally be changed. The field is taken from **[Projects Setup](/docs/pb/setup/general.md)** when a Project is created. ### Fast tab Duration The **Start Date** and **End Date** can be used to maintain the start and (expected) end of the Project for information purposes. Both entries are optional. ## Copying a Project A Project can be copied using the Business Central standard **Copy Project** action, and Project Tasks alone can be copied between Projects using the standard **Copy Project Tasks from** / **Copy Project Tasks to** actions. **DYCE Project Billing** adjusts the result of all three so the copy starts from a clean, correct state rather than one that still reflects the source Project: * **Dimensions:** With **Copy Dimensions** enabled, the Customer and Project dimension values are not copied from the source. Instead, the Customer dimension on the new Project (and its Project Tasks) is re-derived from the new Project's Bill-to Customer, and a new Project dimension value is created for the new Project - the same way both are already set for a newly created Project (see [Autom. Insert Project Dimension Value](/docs/pb/setup/general.md)). Every other dimension is still copied unchanged. With **Copy Dimensions** disabled, dimensions are unaffected by this behavior. * **Source references:** Copied Project Tasks and Project Planning Lines never carry the source Sales Order, Sales Invoice, or Sales Credit Memo reference of the original - these belong only to the original record. * **Status:** A copied Project Task's status is not taken from the source task. It is set to **Open** if the task has at least one Budget Project Planning Line with a Service Billing Type, otherwise to **Time Recording Locked** - the same rule used when a Project Task is created any other way (see [Status of Project Tasks](/docs/pb/masterdata/project-task-planning-line.md#status-of-project-tasks)). --- ## Resources People (employees and external service providers) are created as resources. They provide the services. Proof of completed services is provided in the form of Time Recordings, created by the resources for their respective tasks. These Time Recordings are checked and released via **DYCE Project Billing** (page **Project Billing**). Subsequently, the services completed are invoiced. The resource planning (e.g. with regard to concrete employee assignments) takes place outside of **DYCE Project Billing**. However, this can be done in any other tool. Master data regarding capacity etc. of these employees can be stored so that they can be further processed in other systems if necessary. ## Human resources Time Recordings are always created for a specific human resource. Therefore, each employee who provides services must be set up as a resource (of the type *Person*). * The **No.** field is usually filled manually with a short name for the person ([see below](#suggestion-for-the-naming-of-human-resources)). * In the field **Name** first name and family name are entered. * As **Type** the value *Person* is selected. * In the **Base Unit of Measure** field, the unit of work that will be used as the basis for postings is specified. The lookup will take you to the appropriate selection, usually the base unit *hour* is used for human resources. * The **Resource Group No.** field is used to assign persons to a resource group or team. The field can be used for planning and evaluations. **Locked** is set when the resource may no longer be used. * If a person is an external service provider, the related vendor must be specified in the **Vendor No.** field of the *Invoicing* fast tab. * As a prerequisite for Time Recordings to be posted, a suitable Product Posting Group must be specified in the **Gen. Prod. Posting Group** field. ### Human resources defaults Human resources can and should be given a [capacity](#resource-capacities). It results from the work-hour template, the base calendar (which contains the non-working days) and the absences of the resource. With the **Resource Person Defaults** (action in the menu group *Resource*) there is a convenient option for maintenance in **DYCE Project Billing**. Calling up the action opens the page of the same name. In addition to the work-hour template and the base calendar, the cost center and the resource group can also be specified here by entering a validity date. This makes it possible to enter a planned change in advance. The batch processing behind the **Apply Resource Person Defaults** action transfers the defaults to all relevant places. Individual resources can be filtered for manual execution. The defaults valid on the workdate or calendar day are transferred (taking into account the **Transferred at** and **Valid from** fields) and the [capacity](#resource-capacities) is generated if necessary. Batch processing can be carried out via the resource card, the search or (automatically) via the job queue (report 70920903). When **DYCE Project Billing** is installed, a task is created for daily execution at 3:00 a.m., but is not activated. If an existing default is changed, the **Transferred at** field is reset and a new update is prepared. The resource's Base Calendar Code is also used to classify holidays for surcharge calculation when the Surcharge Model's [Base Calendar Source](/docs/pb/masterdata/surcharges.md#base-calendar-source) is set to *From Resource*. ### Resource capacities To support automated resource planning, resource capacities can be created automatically and kept up to date. The following fields (in the *General* fast tab) are used for this purpose in the **Projects Setup**: * **Create Resource Capacity Entries** determines whether resource capacities are created automatically when person resource defaults are applied. * **Create Resource Capacity Entries from** specifies the dateformula from when capacities should be created. * **Create Resource Capacity Entries until** specifies the dateformula until when capacities should be created. :::tip Select a sensible time period The date formulas can be used to flexibly specify a time period. The following setting is recommended, for example: * **Create Resource Capacity Entries from** = -CM-1M * **Create Resource Capacity Entries until** = CY+1Y This means that the capacities are always created one month in arrears and one year in advance based on the current workdate or date. ::: Batch processing **Apply Resource Person Defaults** takes the setting from **Projects Setup** into account and proposes the creation of capacities accordingly or creates them automatically. The system checks whether resource capacities need to be created or updated. The fields **Resource Capacity created at** and **Valid from** are taken into account. Even if the defaults have not changed, capacities are created for the selected period (manually or via the **Projects Setup**) to ensure that the planning period is covered. For this purpose, the date of the last Resource Capacity Entry is compared with the calculated start date. Capacities are created per calendar day and take into account (per resource): * Work-Hour Template * Base Calendar → non-working days correspond to a capacity of 0 * Absences (*empty*, *Approved* or *Approval Pending*) → capacity is reduced accordingly: * Full day → full capacity is deducted * Half-day → half capacity is deducted * Hourly → corresponding hours will be deducted If the new capacity or related metadata (e.g. resource group, cost center) differs from the existing entry, the old entry is deleted and a new one is created (table *Resource Capacity Entry*, 160). There must be an entry for each calendar day - even with capacity 0. If an existing default or absence is created or changed, the **Resource Capacity created at** field is reset, thus preparing the creation of the new capacity. At the same time, the ideally daily execution ensures that the capacities of the resources are always up to date. In addition, the capacities of the resource groups are also updated automatically if the capacities of individual resources change. The resource capacities are also made available via an API page. :::info Standard action Set Capacity hidden To avoid confusion, the standard action **Set Capacity** on the Resource Capacity page is hidden with the installation of **DYCE Project Billing**, as this functionality is covered by the batch processing **Apply Resource Person Defaults**. ::: ### Placeholder {#placeholder} Resources can be marked as **Placeholder**s. This is for use in **DYCE Project & Resource Planning**. Resources marked in this way behave like a human resource (including **Resource Person Defaults** and **Skills**). When used in a project plan of **DYCE Project & Resource Planning**, however, an assignment to a task does not reduce its required capacity. ### Plannability Resources can be marked as **Planable**. Only resources marked in this way can be used in **DYCE Project & Resource Planning** and **[Work Order Events](/docs/pb/professional-services/work-order.md#work-order-events)**. Please note that plannable resources are subject to a fee if **[DYCE Project & Resource Planning](/docs/web/prp/welcome.md)** or **[DYCE Professional Services Suite Pro](/docs/appsuites/pss-pro.md)** are used (s. [Feature management](/docs/web/administration/setup-web.md#feature-management)). Current pricing information can be found on the website. ## Multiple levels in resource skills It is already possible to define skills and assign these to resources in the standard version of Business Central (call via *Resource / Skills* in the Resource Card). With **DYCE Project Billing**, any number of levels can also be defined for each skill to enable a gradation within a skill. These levels can then be taken into account when assigning a skill to a resource. The **Skill Code Levels** are defined in the page of the same name, which is opened via the lookup in the **Levels** field in the **Resource Skills** page. For a better overview, the **No.** of assigned skills per resource is displayed in the infobox *Resource Statistics*. :::tip Sorting The **Skill Code Levels** are sorted/displayed alphanumerically based on the **Level**. It may therefore be useful to add a leading digit in front of the level for sorting purposes. ::: ## Suggestion for the naming of human resources A uniform naming scheme contributes to general clarity. The following is therefore a proposal for such a scheme for human resources. However, it is important to consider how many letters are needed to ensure a unique code. Thus, both a *Joseph Doe* and a *Jane Doe* may work in the same company. Structure: first three letters of the first name, then the last name . Example: John Doe ==> JOHDOE --- ## Surcharges The basis for surcharges is the surcharge model, which is stored in the master data. Here, different surcharge rates can be defined for various times of day and days of the week. Surcharge models can be found via Alt+Q in the search bar. A new model can be created by clicking *New*. - **Code**: Specifies the unique code of the surcharge model. - **Description**: Provides a short description of the surcharge model. - **Start & End Mandatory**: Specifies whether Start Time and End Time are required on Time Recordings for projects using this surcharge model (see [Start Time / End Time](#start-end-mandatory) below). The setting can be changed at any time; existing Time Recordings are neither checked nor updated retroactively. - **Base Calendar Source**: Determines which Base Calendar Code is used to classify holidays for surcharge calculation (see [Base Calendar Source](#base-calendar-source) below). The surcharges are defined in the surcharge model lines. - **Type of Day**: There are 4 different types of days to choose from (Working Day, Saturday, Sunday, Holiday). Monday to Friday are generally considered working days. Holidays are determined from the calendar selected via **Base Calendar Source**. The service date in the time recording is used to determine the type of day. This allows the relevant surcharge model lines to be found. The type of day is used to calculate surcharges for the time recording. - **Start Time**: Specifies the time from which the surcharge can be applied. 00:00:00 is interpreted as midnight (start of the day). - **End Time**: Specifies the time from which a surcharge can no longer be applied. 00:00:00 is interpreted as 24:00 (end of the day). If the Start and End fields are empty, the surcharge model line applies for the entire type of day (0 to 24h). - **Surcharge %**: Specifies the surcharge to be applied in percent. Surcharge model lines with 0% are ignored when calculating surcharges. Surcharge model lines must not overlap. If the Start and End fields are empty in a line, it applies to the entire type of day. Another model line with the same type of day would be an overlap. ### Start & End Mandatory {#start-end-mandatory} :::info A surcharge model line with a Start Time or End Time other than 00:00 only applies to a Time Recording that itself carries a start and end time - a Time Recording without them cannot be matched against a partial-day line, so its surcharge is silently not applied. **Start & End Mandatory** closes this gap: once enabled on the surcharge model, entering or changing the Project on a Time Recording requires both **Start Time** and **End Time** to be filled (clearing either one afterwards is checked the same way). If they are missing, posting is blocked with an error naming the surcharge model. To help set this up correctly, a notification suggests enabling **Start & End Mandatory** the first time a Start Time other than 00:00 is entered on the first line of a surcharge model that does not yet require it. Enabling the field dismisses the notification for that model. ::: ## Base Calendar Source {#base-calendar-source} For each time recording, only one calendar is evaluated to classify a day as a holiday for surcharge calculation — which one depends on the **Base Calendar Source** field on the Surcharge Model: - **From Project**: The Base Calendar Code stored on the [Project](/docs/pb/masterdata/project.md) of the time recording is used. The resource's Base Calendar Code is ignored. - **From Resource**: The Base Calendar Code stored in the [Resource Person Defaults](/docs/pb/masterdata/resource.md#human-resources-defaults) of the time recording's resource is used. The project's Base Calendar Code is ignored. If the selected calendar is empty, holidays cannot be determined and the type of day falls back to the day of week only (working day, Saturday, or Sunday). :::info Default value New Surcharge Models default the field **Base Calendar Source** to *From Project*. Surcharge Models existing before this setting was introduced default to *From Resource*. On upgrade to a version that introduces the **Base Calendar Code** field, existing projects are backfilled with the base calendar from **Company Information**. ::: --- ## Posting Documents(Pb) # Posting documents Invoices and Credit Memos are called Posting Documents because these documents can be posted. When creating these documents via **[Project Billing](/docs/pb/project-billing.md)**, the system recognizes whether an invoice or a credit memo is to be created based on the underlying Project Planning Lines. This applies to Project Tasks both with and without a link to a Sales Order. ## Invoicing of services Service invoices can be generated in several ways. The **Project Orders - Services Billing** page displays those Sales Orders that contain a service that has been performed but not yet billed. From here, either the Sales Order can be opened and the invoice posted directly through that Sales Order, or the invoices can be generated via batch processing. :::warning Create Sales Invoices Using the action **Create Sales Invoices** in **Project Orders - Services Billing** will create one line in the invoice for each project planning line billable. This means that the structure of the sales invoice may no longer look the same as the sales order, and the position numbers may be duplicated. However, if the sales invoice is created from the sales order (post & invoice), the structure of the invoice will look the same as the sales order. ::: Alternatively, the **Billable Planning Lines** page shows all the Project Planning Lines of the marked Project Tasks without a reference to a sales order, that can be invoiced. Invoices can also be batch generated here. The **Billable Planning Lines** page is opened via **Invoicing** action (action group *Home*) in **[Project Billing](/docs/pb/project-billing.md)**. The **Project Orders - Services Billing** page is thus only suitable for invoicing Sales Orders (with a Project reference). The **Billable Planning Lines** page can be used to invoice services without a link to a Sales Order. Using **Create Sales Invoices**, in either page, opens an **Invoice Dates** dialog asking for the **Posting Date**, **Document Date**, and **VAT Date** to use on the created invoice(s); all three default to the work date and are applied together. The batch processing in the **Billable Planning Lines** page runs through all *Billable* Project Planning Lines without a sales order reference and creates an invoice per Project. It checks for cancelled services, for which the corresponding Credit Memo has not yet been posted. Since Credit Memos for cancelled services have an impact on the budget (see [here](/docs/pb/cancellation.md)), Credit Memos must be posted before a new invoice can be created and posted. Therefore, if (per Sales Order or per Project) a cancelled service is found that has not yet been posted, only the Credit Memo will be created first, but not the invoice. :::note Shipping services In general, the posting of Time Recordings corresponds to the performance and thus the *shipment* of a service. This always creates billable Project Planning Lines and also Project Ledger Entries of type *Usage*. ::: ### Invoicing of Fixed Price Items If the total quantity of a Fixed Price item is reached with the posting (shipment), the **Qty. To Invoice** field is automatically predefined with this quantity. For more information on billing Services at Fixed Price, see [here](/docs/pb/project-billing.md#increase-or-decrease-the-recorded-quantities). ## Previews for Invoices and Credit Memos In addition to the **Preview Posting** from Business Central, DYCE also provides a [Print Preview](/docs/general/essentials/print-preview.md) for Sales invoices and credit memos that have not yet been posted. ## Posting Posting Documents for services or Projects can be posted and printed or sent individually or in batches, as is usual in the Purchasing and Sales areas. Especially in the case of a large number of invoices, it is advisable to check the Posting Documents by batch after they have been generated, to post them in a second batch and, if necessary, also to print or send them via batch. In addition, a **[Detail Overview](/docs/pb/masterdata/project.md#fast-tab-general)** can be automatically added to the invoice for each service invoice. The Detail Overview contains details of the Time Recordings invoiced incl. goodwill times, if applicable. --- ## Additional Services Additional Services allow you to link flat-rate charges – e.g., a travel lump sum, overnight stays, or special surcharges such as an express service – directly to a Time Recording and subsequently invoice them to the customer. **Core Principle:** The link is 1:1. One Time Recording equals exactly one unit of the selected Additional Service, regardless of the recorded work duration. Typical use cases: * Travel lump sum per customer visit * Overnight stay flat rate * Express service or bad weather surcharge * Other flat-rate ancillary services :::info Distinction from Surcharges [Surcharges](/docs/pb/surcharges) are calculated automatically based on time of day and the surcharge model (e.g., night or public holiday surcharges). Additional Services, by contrast, are selected **manually** in the Time Recording and represent a standalone, flat-rate charge. ::: ## Use Cases Additional Services are designed to minimize the effort required to record a supplementary charge. The key idea: the Additional Service is simply added to the Time Recording that needs to be created anyway — no separate Time Recording just for the Additional Service is needed. :::note No Sales Order is required to work with Additional Services. The only prerequisite is a Project Planning Line with Service Billing Type *Additional Service* as a budget. This can be created manually or generated from a Sales Order. ::: ### Travel Expenses A common use case is travel expenses for on-site customer visits. Typically, you and your customer will have an agreement on the amount to be charged — for example, a flat fee per trip. This is reflected in the Sales Order and set up as a Project Planning Line (budget). When running a workshop at your customer's premises, create a Time Recording for the work done as usual and select the Additional Service **"Travel to Customer"** directly in that Time Recording. A separate Time Recording for the travel time itself is not technically required, though you can create one if you want to record the travel time separately. If the workshop spans two days and you decide to stay overnight rather than traveling back and forth, add a second Additional Service **"Overnight Stay"** to the Sales Order. Use it in the Time Recording for the second workshop day, and the overnight stay will automatically be invoiced to the customer. ### Technician Visiting Multiple Customers A technician visiting multiple customers in a single day selects the appropriate Additional Service for each customer's travel in every Time Recording. Each trip is automatically assigned to the correct customer and project and included in the invoice. ### Processing and Activation Fees Some customers charge a flat fee for enabling additional users, licenses, or modules. Since this fee is always the same amount, it is a perfect fit for an Additional Service: the technician creates a Time Recording for the actual work and sets it to *Internal*, so the working time is neither invoiced nor visible in the detail Overview of the invoice. The Additional Service for the activation fee is added and invoiced to the customer separately. :::note As described in [Rules and Behavior](#rules-and-behavior), the non-billable reason of a Time Recording has no effect on the Additional Service — it is posted as billable regardless. ::: ### Express Fee If a customer requests work to be completed as quickly as possible, you can set up an express fee as an Additional Service and add it to the relevant Time Recording. ### Ticket Flat Rates Ticket flat rates can be recorded by the user themselves. However, if every ticket consistently incurs a flat-rate charge, it may be worth having a small customization implemented that automatically adds the Additional Service to the first Time Recording of each ticket. ## Setup Setup begins in master data with the creation of an **item**. The item is created analogously to other service items, with the following differences: * **Service Billing Type:** `Additional Service` (instead of *Time & Material*, *Budget*, or *Fixed Price*) * **Unit of Measure:** Typically *Piece* or another quantity-based unit – **not** hours, since this is a flat-rate charge. The item can be used in quotes and sales orders like other service items. Project Tasks and project planning lines can be created from the sales order. If the Project Task and Budget project planning line are created manually, the item with Service Billing Type *Additional Service* must be selected in the project planning line. :::info Project planning lines with Service Billing Type *Additional Service* are **not** shown in the standard lookups for **Activity**, **Project Planning Line**, and **Project Task** in the Time Recording, in order to prevent accidental entries. Access is only possible via the dedicated Additional Service fields. ::: ## Time Recording with Additional Service ### Fields in the Time Recording The following fields are available to link an Additional Service to a Time Recording. They are hidden by default and can be shown via personalization: | Field | Description | |:---|:---| | **Additional Service Description** | Select the Additional Service via the description of the project planning line (lookup) | | **Additional Service Planning Line No.** | Direct entry or selection of the project planning line (lookup) | | **Additional Service Project Task No.** | Selection of the associated Project Task | The three fields complement each other: filling in one automatically completes the others, provided the result is unambiguous. ### Rules and Behavior * **Project:** The Additional Service must belong to the same project as the Time Recording. If the project on the Time Recording is changed, the Additional Service is automatically cleared. * **Project Task status:** * *Open* – Additional Service can be selected. * *Locked* or *Closed* – Additional Service cannot be selected. * **Non-billable Time Recordings:** The *Non-Billable Reason* of a Time Recording (e.g., Goodwill/Warranty) has **no effect** on the Additional Service. The Additional Service is posted as billable regardless of the billable duration of the Time Recording. ### Work Order Lines Additional Services work the same for **both** Budget Types (Open and Project): the Additional Service can be selected regardless of whether a Work Order Line for it already exists. When a Time Recording with an Additional Service is saved, the system automatically creates the corresponding Work Order Line if it does not yet exist. For further information on Work Order Lines, see the [Work Order documentation](/docs/pb/professional-services/work-order#4-work-order-lines). ## Approval and Posting Time Recordings with Additional Services are approved and posted like regular Time Recordings. When a Time Recording with an Additional Service is released, the quantity to invoice of the Project Planning Lines or Work Order Lines is increased by 1. When posting, in addition to the project planning line (billable) for the Time Recording, a second project planning line (billable) is created for the Additional Service. Since the Time Recording and the Additional Service are generally assigned to different Project Tasks, these project planning lines (billable) are created in their respective Project Tasks. ### Without Work Order When posting, all Time Recordings with the same Additional Service are counted. If a project planning line (billable) for the Additional Service already exists (without an Invoicing Document Type), its quantity is increased. Otherwise, a new project planning line (billable) is created. ### With Work Order The quantity to invoice of the Work Order Line for the Additional Service determines, at the time of posting, whether a new project planning line (billable) for the Additional Service is created or an existing one is updated. ### Quantity Overflow (Automatic Increase) If the quantity in the project planning line or sales order is exceeded, the system automatically increases it upon posting – analogous to the *Time & Material* service billing type. ### Cancellation When a posted Time Recording is cancelled, the linked project planning line (billable) of the Additional Service is automatically reversed as well. ## Invoicing Project planning lines (billable) for Additional Services are invoiced like regular billable project planning lines in Project Billing. In the **detailed invoice overview**, the Time Recording is listed normally and additionally in abbreviated form for the Additional Service below it. In Project Billing (Overview/Approval), the **Additional Service** column can be shown via personalization. It indicates whether open or released Time Recordings with an Additional Service are present. --- ## Creating Work Orders from Sales Orders **DYCE Project Billing** allows you to create and manage work orders directly from a sales order. A dedicated **Work Orders** action on the sales order opens a filtered list showing only work orders linked to the current sales order, giving a clear and consolidated overview of all related work orders in one place. New work orders created from this view are automatically linked to the sales order and pre-populated with the relevant header data. ## Creating a Work Order {#create-wo-from-so} Open the sales order from which you want to create work orders. The **Work Orders** action (*Related* and *Home* tab) is only enabled if the sales order has a **Project No.** assigned. Once the action is triggered , the **Work Orders** list page opens, pre-filtered to show only work orders linked to the current sales order. Choose **New** to create a new work order. The work order card opens automatically, pre-populated with the **Customer** and **Project** from the sales order, and with **Budget Type** set to *Project*. :::info The work orders list opened from a sales order is always filtered to that sales order. It is not possible to create or view work orders for a different sales order from within this filtered context. ::: To add work order lines, go to the **Lines** tab and choose **Add Lines from Project Planning Lines**. The selection page lists all available Project Planning Lines for the assigned project. Lines linked to the current sales order are **highlighted** for easier identification. Select the relevant lines and confirm to add them to the work order. For more details on work order line behavior and rules, see [Work Order Lines](/docs/pb/professional-services/work-order.md#41-creating-work-order-lines) and [Work Order Business Rules](/docs/pb/professional-services/work-order-business-rules.md). The work order is also linked back to the originating sales order via two read-only header fields: **Source Document Type**, set to *Order*, and **Source Document No.**, set to the sales order number. Both fields are hidden by default and can be added to the layout using personalization. The same fields are also available on the work order lines, with the addition of **Source Document Line No.** All three fields are informational, hidden by default, and can be added to the layout using personalization. :::tip Billing work orders and sub-work orders When a work order is assigned to a billing work order by setting the **Billing Work Order No.** field, the sub-work order automatically inherits **Source Document Type** and **Source Document No.** from the billing work order. For more details on the structure of a work order, see [here](/docs/pb/professional-services/work-order.md#1-details-and-hierarchy-for-whom). ::: :::info When the **Customer No.** or **Project No.** is changed on the work order card, **Source Document Type** and **Source Document No.** are automatically cleared, because the link to the originating sales order is no longer valid. ::: A work order can also be created directly from a customer record. On the **Customer List** or **Customer Card**, use the **New Document** action group and choose **Work Order**. The new work order card opens pre-populated with the customer. From here, the work order follows the standard process of time recording, approval, and billing, as described in [Work Order](/docs/pb/professional-services/work-order). --- ## Introduction # Professional Services In the context of **DYCE**, this term refers to activities performed by specialists or experts in a specific field. In IT and IT consulting, these are services provided by IT experts who support companies in the implementation and maintenance of IT systems. This also includes the deployment of IT specialists, employees in (technical) support, as well as companies in the fields of software development or managed service providers. Other examples - outside of IT - include services provided by lawyers or legal advisors, or the activities of tax consultants or auditors. ## Planning, Budgeting, and Billing for Services One of the goals of DYCE is to map the entire value creation process for services. Several **DYCE** apps work hand in hand to achieve this: **DYCE Project Billing** for administrative management, **DYCE Time Tracking** for recording time, **DYCE Project & Resource Planning** for scheduling projects and services, and optionally **Jira** and **Azure DevOps** as connected systems. For recording and billing time, project tasks/planning lines are required to which the recorded times relate. The project tasks/planning lines can optionally be linked to a sales order, [created from a Customer Subscription Contract](/docs/pb/professional-services/project-planning-lines.md), or be independent, i.e., have no connections. The times recorded against project tasks/planning lines can be invoiced, which is typically done on a periodic basis (e.g., monthly). There are two options for time tracking. The first relates directly to the project task and is suitable, for example, for (non-billable) contractual services, small orders ("2 days of training"), or when billing is generally done against a large budget pool. The other is the reference to a **work order**, which makes it possible to split a project planning line into multiple sub-budgets. ## Work Order In **DYCE**, time can be recorded directly on project tasks, which can be created with any level of detail within the projects. However, especially in large projects with different budgets and multiple people involved, splitting the budget items of a sales order into numerous project tasks and planning lines can be cumbersome and prone to errors. This is where the so-called **work orders** come into play with **DYCE Project Billing**. A **[work order](/docs/pb/professional-services/work-order.md)** is a central document that supports the execution and billing of a specific job, task, or service. It serves as a focal point for communication, planning, execution, and tracking of work packages of all kinds — from internal maintenance tasks to tasks in complex, billable customer projects. In essence, a work order answers the fundamental questions about a task: * **What** is to be done? * **For whom** is the work being done? * **Who** is responsible for the execution? * **When** should the work take place? * **How** will the effort be billed? Work orders are the link between planning (**DYCE Project & Resource Planning**), operational execution (time tracking in **DYCE Time Tracking**), and the subsequent commercial processing (**DYCE Project Billing**). ## Integration of Jira and Azure DevOps In **DYCE**, work orders can exist on their own or act as a link to external systems like **Jira** and **Azure DevOps**. The ITSM solution **Jira Service Management / Software** covers topics such as support, software development with change requests, approval of effort estimates, and external communication. Alternatively to **Jira**, service delivery can also take place in **Azure DevOps** (though without a portal in that case). The system in which the users work is irrelevant - work orders are present everywhere: * in **DYCE Time Tracking** and **DYCE Project & Resource Planning**, * in **Jira**, the Issues (from 2025: Work Items) correspond to work orders; in **Azure DevOps**, they are the Work Items. If an external system is used, work orders are derived and synchronized from it. The connection of other systems (e.g., other ITSM / helpdesk solutions) can also be realized via the work order and its related entities. ## Further Information This page provides an overview of how services can be billed with **DYCE**. Around this core, there are many other modules that cover further requirements. These include: * Long texts for task descriptions, internal notes, solutions, etc. * Centralized & visual scheduling (in **[DYCE Project & Resource Planning](/docs/web/prp/welcome.md)**) * Time tracking on work orders (with different entry points) * Status to describe the state of a work order (Example: Time trackers can report completion) * Selection of work orders in billing according to various criteria, such as billing all completed work orders * Consideration of further details, such as effort estimates --- ## Project Billing (Approval) The **Project Billing (Approval)** page is the work-order-centric counterpart to the standard [Project Billing](/docs/pb/project-billing.md) page. Where Project Billing organizes time recordings only by project task, Project Billing (Approval) organizes them by Billing Work Order, if they belong to a work order — making it the preferred starting point when Work Orders are used. Project Billing (Approval) can be used for time recordings wthout work orders without any downside. **Typical personas:** - **Project Manager** — reviews and releases open time recordings for the work orders they are responsible for. - **Inside Sales** — posts all released time recordings and prepares the project for invoicing. **Prerequisite:** Work Order Posting must be enabled in Project Setup. See [Work Order Posting](/docs/pb/setup/general.md#work-order-posting). **Access:** Open via the Role Center or search (`Alt+Q`) for *Project Billing (Approval)*. --- ## Project Billing Presets {#presets} ### What Are Presets? {#what-are-presets} Presets are per-user filter sets that control which data is loaded into the Project Billing (Approval) page. Each user sees only the presets assigned to their own User ID — this prevents users from accidentally working in each other's views. Presets are managed centrally on the **Project Billing Presets** page (typically by a designated key user such as a project management lead). The key user creates and maintains all presets and distributes them to users using the copy actions described below. :::tip Recommended Approach Create the complete set of presets once, then use **Copy to User(s)** to distribute them. Users should not need to manage their own presets. ::: ### Creating and Distributing Presets {#creating-presets} User can create and edit their own presets by opening the list of their presets in Projekt Billing (Approval). A central distibution is ussually easier on the user. To distribute the presets centralized please follow the steps below. 1. Open the **Project Billing Presets** page (search `Alt+Q`). 2. Create one preset user per use case — set the **User ID** field to the target user. 3. To duplicate an existing preset for the same user (for example, create a *To Post* variant from a *To Release* preset), select the row and use **Copy Preset**. 4. To copy one or more presets to other users, select the presets and use **Copy to User(s)**. This is the primary distribution mechanism. ### Preset Fields {#preset-fields} | Field | Description | |---|---| | Description | Name of the preset | | Time Recordings Formula | DateFormula (e.g. `<-CM>`) for dynamic date calculation. Populates *Show Time Recordings up to* automatically. | | Display Unit | Hour or Day — controls how quantities are shown | | My Projects | When enabled, shows only projects listed in **My Projects** (Role Centers **DYCE Project Administrator** and **Project Manager**) | | Time Recording Filter | **To Release** displays the record (work orde or project task) if at least one open time recording and **To Post** at least one released time recording exists | | Sorting | **By Customer** or **By Project** — controls header row ordering (see [below](#sorting)) | | Project Filter | Optional: filter for one or more projects | | Work Order Filter | Optional: filter for specific work orders | **Recommended presets:** | Role | Time Recordings Filter | My Projects | |---|---|---| | Project Manager | To Release | Yes | | Posting Clerk | To Post | No | Project Manager should have a preset for each process, to organize releasing time recordings more efficiently. Organizing the projects by project type enables the project manager to do so. Typical examples for project types are *implementation* and *maintenance*. This allows to release planned and most likely invoicable time recordings and unplanned services (bugs) in seperate steps. Seperating the steps grants the opportunity to focus on the context. Bugs are often not invoiced, while planned services are usually invoiced completely but needs budget controlling. Additional filters like work order type and closed can refine the process. ### Preset Factboxes {#preset-factboxes} The **Presets** and **Project Billing Presets** pages show the content of the selected preset in three factboxes, so a preset can be checked without opening its filter dialogs: | Factbox | Content | |---|---| | Preset Details | **Description** and **Time Recording Filter** of the preset. Further preset fields (e.g. **Sorting** or **Display Unit**) can be added via personalization. | | Project Filter | One row per applied criterion of the project filter, with the columns **Field** and **Value** | | Work Order Filter | One row per applied criterion of the work order filter, with the columns **Field** and **Value** | The **Edit** action in the **Project Filter** and **Work Order Filter** factboxes opens the corresponding filter dialog directly (see [Filter Behavior](#filter-behavior)). Changed criteria are shown in the factbox immediately after the dialog is confirmed. ### Filter Behavior {#filter-behavior} Every field on the **Project Filter** and **Work Order Filter** dialogs - except the plain Yes/No/blank dropdowns - accepts standard Business Central filter syntax, the same as any filter field elsewhere in Business Central: - **Exclude** a value with `<>`, and combine several exclusions, e.g. `<>PROJ001&<>PROJ002` - **List** several values with `|`, e.g. `Handling Error|Missing Setup` - **Range** with `..`, e.g. `Job000001..Job000099` - **Wildcard** with `*`, e.g. `C*` A plain value with no operator characters still matches exactly, the same as before. There is no length limit on any of these fields - a filter expression of any length is accepted and stored in full, never truncated. The lookup button on each of these fields opens a list that allows selecting more than one row; confirming a multi-selection replaces the field's entire content with a filter expression joining the selected values with `|`. **Project No.** and **Sell-to Customer No.** use a range filter instead (e.g. `A..C`), where the selection allows it. The only fields that stay a plain dropdown, without filter syntax or a multi-select lookup, are **Closed** and **Blocked** on the Work Order Filter. The **Show Time Recordings up to** header field is unaffected either way - it remains a simple upper date boundary. :::note Filters are continuously extended Project Billing (Approval) uses a query to filter. This is necessary to filter in multiple tables (work orders, projects and time recordings), while keeping the processing time low and showing better performance. The backdraw is that every filter must be coded individually. New filter options are added regularly. If a filter that you need for your use case is missing, report it to your Business Central partner. ::: ### How the Sorting Field Changes the Page {#sorting} The **Sorting** field (and the **Sort by Customer** / **Sort by Project** action buttons on the page) controls the order of the bold header rows only — it does not change which lines are grouped together. - **By Customer:** Header rows are sorted by Customer Number, then by Project and Sales Order Number within each customer. - **By Project:** Header rows are sorted by Project Number, then by Sales Order Number within each project. The Project Billing (Appoval) page should be personalized based on the selected **Sorting**, to underpin the prefered way of working. Make sure to display the Project No. first, if sorting by project and Sell-to Customer Name, if sorting by project has been selected. Otherwise the order in which the header lines are displayed appear random. Please note, that the Project Billing (Appoval) page must be closed and opened after personalization to rebuild the tree view. --- ## The Page Structure {#page-structure} ### Header Fields {#header-fields} | Field | Description | |---|---| | Project Billing Preset | Selects the active preset. Changing this field clears and rebuilds all page data. | | Show Time Recordings up to | Date filter — only time recordings with a Service Date on or before this date are shown. This field does **not** affect which time recordings are included when posting. It only has effect on releasing.| | Posting Date | The date written to Project Ledger Entries and Project Planning Lines (Billable) when time recordings are posted. | ### Line Hierarchy and Grouping {#line-hierarchy} The page displays data in two levels: **Level 1 — Bold header lines (Line Type: Project)** A new bold header line appears for each unique **Customer + Sales Order** combination (when sorting by customer) or **Project + Sales Order** combination (when sorting by project). All Work Orders and Project Tasks for that combination are grouped beneath it. A Sales Order usually represents a dedicated budget. Grouping by it makes it possible to work within its context and budget. **Level 2 — Detail lines** | Line Type | What It Represents | |---|---| | Project Task | Displays project tasks for time recordings recorded without a Work Order | | Work Order | Displays Billing Work Orders. A Billing Work Order; aggregates time recordings from all its Sub-Work Orders | :::info Sub-Work Orders are not shown as separate rows Sub-Work Orders are consolidated under their Billing Work Order. All their time recordings appear on the Billing Work Order row, not separately. ::: ### Fields on Detail Lines {#detail-line-fields} | Field | Notes | |---|---| | Number | The number of the project (header line), project task, or work order — depending on line type. Click to open the corresponding card. | | Title | Title of the work order or description of the project task | | Original Estimate | Planned effort (work orders only) | | Time Recordings Open | Sum of the duration of open time recordings. Click to open the detail page for review and individual release. | | Time Recordings Released | Sum of the duration of released time recordings. Click to inspect. | | Quantity Billable Open | Total billable duration of open time recordings | | Quantity Billable Released | Total billable duration of released time recordings | | Additional Service | Indicates whether open or released time recordings with Additional Services are present (visible by default; can also be shown via personalization if hidden) | **Visual indicators:** - Header lines are displayed in **bold**. - Detail lines where the billable duration exceeds the budget are highlighted in **red**. (Service Billing Type Time and Material will not be indicated in red, because the budget is automatically extended, when posting.) --- ## Which Lines Are Displayed and Why {#displayed-lines} The page only shows data that matches the active preset's filters: - Only time recordings matching the preset's Project, Work Order, and Time Recording filters are included. - Only time recordings with a **Service Date ≤ "Show Time Recordings up to"** are included. - The **Time Recording Status Filter** determines the focus: - **To Release:** Shows lines that have at least one Open time recording. - **To Post:** Shows lines that have at least one Released time recording. - In both cases, a line always shows **all** time recordings (both Open and Released) to give the full picture. The status filter only determines *which lines appear*, not which time recordings are visible on each line. :::warning Data is user-specific and not live The data shown is built specifically for the logged-in user based on the preset. Updates by other users (for example, new time recordings submitted by a colleague) are **not** automatically reflected. Use **Refresh** to reload. ::: --- ## The Refresh Action {#refresh} The Project Billing (Approval) page does **not** update automatically. All data must be rebuilt manually using **Refresh**. Refresh clears all existing rows and repopulates the page based on the current preset and the current *Show Time Recordings up to* date. Project Billing (Approval) is automatically refreshed, when changing the preset. :::warning If you leave the page and return, the previously loaded data may still be visible, but it reflects the state at the time of the last Refresh. Always Refresh before acting on the data. ::: --- ## Actions {#actions} | Action | Scope | Description | |---|---|---| | Refresh | — | Rebuilds all page data from the current preset and date | | Release | Selected lines | Releases all open time recordings of the selected lines | | Reopen | Selected lines | Sets released time recordings back to Open for the selected lines | | Post | Selected lines | Posts all released time recordings for the selected lines (requires Work Order Posting enabled) | | Sort by Customer | — | Sorts bold header lines by Customer Number (ordering only, not grouping) | | Sort by Project | — | Sorts bold header lines by Project Number (ordering only, not grouping) | --- ## Releasing Time Recordings {#releasing} ### Prerequisites {#release-prerequisites} A time recording can only be released if **all** of the following conditions are met: 1. **Service Date** is filled. 2. **Resource Number** is filled. 3. **Duration** is greater than 0. 4. A **Budget Project Planning Line** is assigned. 5. **Description** is filled. 6. *(When Work Order Posting is enabled)* A matching **Work Order Line** exists for the Work Order and Project Planning Line combination. :::info Work Order Lines and the Approval page When Work Order Posting is enabled, time recordings are only shown on the Project Billing (Approval) page when a corresponding Work Order Line exists. Without a matching Work Order Line, the time recording will not be displayed. ::: ### How to Release {#how-to-release} - **Bulk release:** Select one or more lines and choose **Release**. All open time recordings beneath the selected lines are released at once. - **Individual release:** Click the **Time Recordings Not Released** count on a line to open the detail page, where individual time recordings can be reviewed and toggled. ### After Release — Quantity to Invoice Is Updated {#after-release} When a time recording is released, the **Quantity to Invoice** is recalculated: **Without Work Order Posting:** Quantity to Invoice is set on the **Project Planning Line (Budget)** — calculated as the sum of the billable duration of all released time recordings for that line. **With Work Order Posting:** Quantity to Invoice is set on the **Work Order Line** — calculated individually per Work Order. - **Budget and Fixed Price:** The Quantity to Invoice is capped at the Reserved Quantity on the Work Order Line. It cannot exceed this value. If the Reserved Quantity is empty in the Work Order Lines or the time recording was created without a work order, the Quantity to Invoice cannot be larger than the Quantity of the Project Planning Line (Budget) minus the Quantities of the Project Planning Lines (Billable) and the blocked budget. Budget is blocked because it either has been reserved in another Work Order Line or the Quantity to Invoice of other Work Order Lines, if they do not have a reservation either. - **Time and Material:** No cap. The Quantity to Invoice reflects the full billable duration. The Reserved Quantity and Quantity of the Project Planning Lines (as well as Sales Line) will be updated when posting the time recordings. - **First-come, first-served:** When multiple Work Orders share a Project Planning Line without a Reserved Quantity, the first Work Order to release its time recordings locks in the Quantity to Invoice. Remaining budget may then be insufficient for subsequent Work Orders — these will be highlighted in red. For a detailed explanation of the reservation logic, see [Work Order Posting](/docs/pb/setup/general.md#first-come-first-served). --- ## When Lines Disappear {#lines-disappear} Lines are removed from the page automatically when there is nothing left to act on: - **To Release** preset: A line disappears when all its time recordings are Released or Posted — there is nothing left to release. - **To Post** preset: A line disappears when all its time recordings are Posted — there is nothing left to post. This is intentional behavior. After lines disappear, use **Refresh** to verify whether any new time recordings have appeared since the last rebuild (for example, submitted by colleagues after the page was last loaded). :::info Work Order not disappearing If a work order does not disappear from the list, one or more time recordings have not been released. If the time recording is not displayed in the details page, there can be multiple reasons. - **The Work Order Line is missing:** Use the action **Create Lines** to create potentially missing Work Order Lines. If no lines are created, open and filter the time recordings page. - **Time recording has no project task and project planning line:** Find the time recording in **Time Recordings** *(Alt + Q)*. Note that the time recording may belong to a Sub-Work Order. Filtering by Billing Work Order No. is easier. ::: --- ## Posting Time Recordings {#posting} ### What Posting Does {#what-posting-does} Posting progresses time recordings from Released to Posted and creates the financial records required for invoicing: 1. **Time Recording status** changes: Released → Posted. 2. **Project Ledger Entries (Usage)** are created. When Work Order Posting is enabled, the Work Order Number and Billing Work Order Number are stored on each entry. 3. **Project Planning Lines (Billable)** are created or updated: - Without Work Order Posting: one Project Planning Line Billable per Project Planning Line Budget. - With Work Order Posting: one Project Planning Line Billable per Work Order Line (Billing Work Order + Project Planning Line Budget combination). 4. **Linked Sales Order Lines** are updated (Quantity Shipped and Quantity to Invoice). ### Billing Type Behavior on Posting {#billing-type-behavior} | Billing Type | Behavior | |---|---| | Time and Material | All billable time is posted and invoiced. The Quantity of the Project Planning Line and the linked Sales Order Line is automatically increased when posted time recordings exceed the planned quantity. | | Budget (Capped) | Time recordings can be posted beyond the budget ceiling, but only up to the ceiling is invoiced. | | Fixed Price | Time recordings track effort only. Invoicing is driven by completion of the work, not by total duration. | ### Running the Post {#running-the-post} - **In Project Billing (Approval):** Select lines and choose **Post**. Only the selected lines are posted. - **Unattended via Job Queue:** Report 70920909 "Post Time Recordings" can be scheduled to run automatically. It skips any time recordings that cannot currently be posted (e.g. Status = Open) and continues with the rest. --- ## Invoicing {#invoicing} ### With a Sales Order {#invoicing-with-sales-order} Project Planning Lines (Billable) that are linked to the Sales Order are invoiced in the Sales Order. :::info **Project Orders - Services Billing** The invoice structure is driven by Project Planning Lines (Billable), not by the original Sales Order Lines. If multiple Billing Work Orders each have their own Project Planning Line Billable under the same Sales Order Line, you may see more invoice lines than Sales Order Lines. ::: ### Without a Sales Order {#invoicing-without-sales-order} Use the **Project Create Sales Invoice** function on the project card to create an invoice directly from the project. :::warning Credit memos must be posted first If any posted time recordings have been cancelled and the resulting credit memos have not yet been posted, new invoices cannot be created. Post all outstanding credit memos before creating new invoices. ::: ### Effect of Work Order Posting on Invoice Structure {#invoice-structure} When invoicing without a Sales Order, Work Order Posting changes how invoice lines are created. Each Work Order Line (Billing Work Order + Project Planning Line Budget combination creates a Project Planning Line Billable, which will in turn create a sales invoice line. The Detailed Overview of the posted sales invoice will automatically detail the Work Orders and its time recordings. For details on the full comparison of behavior with and without Work Order Posting, see [Work Order Posting](/docs/pb/setup/general.md#work-order-posting). --- ## Creating Project Planning Lines from Contracts **DYCE Project Billing** allows creating Project Tasks and Project Planning Lines directly from a **Customer Subscription Contract** or a **Subscription**, without navigating to the project separately. A dedicated **Project Planning Lines** action on the contract or subscription gives a consolidated view of all planning lines already linked to that document and provides the option to create new ones. Each task created this way automatically records its source through the **Source Type** field (*Contract* or *Subscription*), making the connection between the contract and the related project work explicit and traceable at all times. ## Project Planning Lines Page {#access} The **Project Planning Lines** action is available on the **Customer Subscription Contract card**, **Subscription card**, and **Customer Subscription Contracts list** in the *Navigate* and *Related* tabs, and in the line-level context menu of any **Contract line** or **Subscription line**. The page title shows the document number and customer name, extended with the line number when opened from a specific line. The page is only accessible from the contract or subscription, not via the search bar. The fields **Source No.**, **Source Line No.**, and **Project No.** are drill-down links. **Description**, **Quantity**, and **Status** can be edited inline and update the task description, planning line quantity, and task status respectively. The fields **Project Task No.** and **Description** are hidden by default and can be shown via *Personalization*. New Project Planning Lines are created from the **Create** action in the action bar. The process is described in the section below. ## Creating a Project Planning Line {#create} Choosing **Create** in one of these pages opens a card page (**Create Project Planning Line**) where a single Project Task and Project Planning Line is created after confirmation. The **Contract / Subscription** field is read-only and shows the document the page was opened from. Depending on the context, it is captioned either *Contract* or *Subscription*. If the action was opened from a specific line, the **Line No.** field is pre-filled and the lookup is restricted to lines of that contract or subscription. Otherwise the field is optional and can be used to associate the new task with a specific contract or subscription line. The **Project No.** is required and is filtered to projects for the source customer. Selecting a project enables **Item No.**, limited to items with a [Service Billing Type](/docs/pb/masterdata/item.md#differences-in-service-billing-items). Once an item is selected, **Quantity** and the optional **[Prepaid Service No.](/docs/ps/masterdata/prepaid-service.md)** field are enabled. When a Prepaid Service No. is specified, it is assigned to both the Project Task and the Project Planning Line on creation. **Unit Price** and **Unit Cost** on the resulting Project Planning Line are taken from the item, the same way they are for a Project Planning Line created manually or from a Sales Order. The **Description** defaults to the source type and document number. When a line is selected, the line description is also included. The value can be changed before confirming. Confirming with **OK** creates the Project Task and Project Planning Line, ready to be invoiced like any other Project Planning Line once Time Recordings are posted against it. Time can then be recorded against the Project Task directly (see [Time Recording](/docs/pb/time-recording.md)) or through a [Work Order](/docs/pb/professional-services/work-order.md). Every Project Task carries a **Source Type** field visible on the Project Tasks page. For tasks created manually or from a Sales Order, this field already existed with the values *(empty)* and **Order**. Two new values extend this: - **Contract**: the task was created from a Customer Subscription Contract. - **Subscription**: the task was created from a Subscription. The **Source Type** and the corresponding **Source No.** are set automatically when a task is created by **Create** action, e.g., through **Create Project Planning Line** card. They cannot be edited manually on the Project Tasks page, ensuring the origin of every task remains reliable. When a Project Task is created with a **Line No.** selected, it inherits dimensions from the selected Contract Line or Subscription Line. If no line is selected, dimensions are taken from the contract or subscription header. If the same dimensions are defined both on the contract or subscription and via the item or project selected on the creation wizard, the values from the wizard take priority. Any remaining dimensions not provided by the item or project are copied from the contract or subscription. Project Tasks and Planning Lines linked to a contract are automatically maintained when the contract changes. If a contract or subscription line is deleted and no [Time Recordings](/docs/pb/time-recording.md) exist against the linked task, both the task and its Planning Line are deleted. When a contract line is set to *Closed* or when the contract is deactivated (**Active** = *No*), all linked tasks are closed. If Time Recordings exist on the task, the status is set to *Time Recording Locked* instead. --- ## Work Order Business Rules # DYCE Work Order Business Rules ## 1. Introduction ### Purpose The authoritative reference for how Work Orders, Work Order Lines, and Time Recordings behave and constrain each other. It states what is allowed, what is forbidden, and — where it isn't obvious — why. ### Audience Developers and integrators implementing or debugging work order behaviour across DYCE Connect, Business Central, and connected systems (Jira, Azure DevOps). ### Scope These rules are platform-agnostic: they hold regardless of the interface used. Rules that apply to only one system are tagged **(Jira)** etc. ### How to read this document Almost every rule is a guard over the same small state. So the document is built bottom-up: - **[§3 State](#state)** defines what a work order *is* — the data every rule operates on. - **[§4 Invariants](#invariants)** are the properties that are always true. They are stated once and referenced by name everywhere else; the big one is the [Structural Lock](#structural-lock). - **[§5 Operations](#operations)** is the working reference: every mutation you can perform, each in the same shape — **Guard** (when it is blocked or required), **Effect** (what changes), and **Why** where it isn't obvious. You look up the operation you're about to do. - **§6–8** cover invoicing behaviour, reservation, and quick-reference tables. Rules are named, not numbered. (Earlier versions numbered them `X.Y`; that index is preserved in the [appendix](#appendix-legacy-rule-number-index) **for historic reference only**.) ## 2. Glossary | Term | Abbreviation | Definition | |------|--------------|------------| | Work Order | WO | A discrete unit of work that can be tracked, budgeted, and billed | | Billing Work Order | BWO | The work order that serves as the aggregation point for billing. Time and costs from related work orders roll up to this level | | Sub-Work Order | Sub-WO | A work order that references a different work order as its BWO | | Project | - | Container for planned work, linked to a Customer (technical name in BC: "Job") | | Project Task | PT | A unit of work within a Project (technical name in BC: "Job Task") | | Project Planning Line | PPL | A budget allocation line within a Project Task. Exists in two types: Budget (planned) and Billable (actual) | | Project Ledger Entry | PLE | A record created when posting and/or invoicing time recordings | | Work Order Line | WOL | A record that links a work order to a Project Planning Line, defining what budget is available for that work order | | Time Recording | TR | A record of actual time spent on work | | Activity | - | The type of work being performed (e.g. consulting, development, testing). Derived from the Time & Travel Model | | Budget Type | - | A work order setting controlling how strictly work order lines are enforced: "Open" or "Project" | | Service Billing Type | - | How a work order line is invoiced: "Time & Material", "Budget", or "Fixed Price" | | Organisation | - | External representation of a Customer in service management systems (e.g. Jira Service Management) | | Asset | - | Linkable representation of Customers, Contracts, or Projects in external systems | ## 3. State — what a Work Order is {#state} Every rule below is a function over this state. ``` Customer └── Project └── Project Task (PT) └── Project Planning Line (PPL) ← the budget Work Order ├── Billing Work Order → itself, or one other WO (the BWO) ├── Budget Type → Open | Project ├── Customer / Project (owned by the BWO — see BWO Ownership) ├── Work Order Lines → each links the WO to one PPL └── Time Recordings → each records effort against a PPL; status Open|Released|Posted ``` A **work order** is a discrete work package. Its **Billing Work Order** is either itself (a standalone/billing WO) or another work order it bills through (making it a **Sub-WO**). A **billing group** is one BWO plus the Sub-WOs that point at it. **Work order lines** link the WO to Project Planning Lines, defining the budget it may consume. **Time recordings** capture actual effort against a PPL and move through three statuses: | Status | Meaning | Editable | Deletable | |--------|---------|----------|-----------| | Open | Draft / not yet approved | Yes | Yes | | Released | Approved for billing, quantity calculated | No (re-open only) | No | | Posted | Financially processed, ledger entries created | No (cancel only) | No | Each step is a stronger financial commitment and removes flexibility. ### Budget Type {#budget-type} The Budget Type sets how strictly recordings are bound to the work order's lines: - **Open** — flexible. A recording may use any PT/PPL of the WO's Project; if its PPL has no line yet, a line is auto-created. For reactive work where budget isn't known upfront (support tickets, ad-hoc requests). - **Project** — strict. A recording may *only* use PT/PPLs that already have a work order line; lookups are filtered to those, and with no lines the PT/PPL fields are disabled. For planned work with pre-allocated budget (implementation projects, sales orders). Can only be set once a Customer and Project are assigned. ## 4. Invariants {#invariants} Properties that are always true. Stated once here; referenced by name throughout [§5](#operations). ### BWO Ownership {#bwo-ownership} **The BWO owns the Customer, Project, and Budget Type for its whole billing group.** A Sub-WO mirrors these three fields from its BWO and cannot override them directly; changing them on the BWO cascades to every Sub-WO. This keeps a billing group billable as a unit — one Customer, one Project, one enforcement mode across it. ### BWO Lines {#bwo-lines} **Work order lines live on the BWO.** The BWO holds the master set; a Sub-WO's lines are a subset, each referencing its BWO master line. A Sub-WO can never hold a line absent from its BWO — it cannot claim budget the BWO didn't allocate. Assigning a BWO line to a Sub-WO is a deliberate act, never automatic. ### Flat Hierarchy {#flat-hierarchy} **A work order's BWO is itself or exactly one real BWO — never deeper, never a loop.** | Configuration | Allowed | |---------------|---------| | WO-01 → WO-01 (self) | Yes | | WO-01 → WO-02, WO-01 → WO-03 (one level) | Yes | | WO-01 → WO-02 → WO-03 (two levels of indirection) | **No** (nesting) | | WO-01 → WO-02, WO-02 → WO-01 | **No** (loop) | A BWO in use by Sub-WOs must be its own BWO (a corollary of the two-level limit). Deeper hierarchies complicate billing; loops would present the same recording twice in Project Billing. ### The Structural Lock {#structural-lock} **Existing time recordings prevent you from restructuring a work order out from under them.** It governs four operations: [Change the Billing Work Order](#change-bwo), [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project), [Delete a work order](#delete-work-order), and [Delete a work order line](#delete-line). Once recordings exist, the changes that would orphan or misroute them — or remove the budget they hang on — are blocked. Strength depends on Budget Type and the most advanced status among the recordings, checked across the **whole billing group** (rows below are the most advanced status present): | Time recording status | Open budget | Project budget | |------------------------|-------------|----------------| | None | allowed | allowed | | Open | allowed | **blocked** | | Released / Posted | **blocked** | **blocked** | **One operation is stricter than the table:** [Delete a work order line](#delete-line) is blocked by **any** recording in **both** budget types — because an Open recording can't be released without its line, if Work Order Posting enabled = Yes. The table governs the other three. **Why it exists:** Released and Posted recordings were approved and posted under a specific Customer, Project, and billing aggregation; the gated operations would route them somewhere they were never approved, or cut them off from the budget line that carries their Quantity to Invoice. With Budget Type = Project the binding is total — recordings must use the work order's Customer, Project, and lines — so even an Open recording freezes the structure. With Budget Type = Open no such binding exists (recordings may deviate from the header), so only Released/Posted recordings, which carry financial commitment, lock anything. ## 5. Operations {#operations} Each operation lists its **Guard** (when blocked or required), **Effect** (what changes), and **Why** where it isn't obvious. ### 5.1 Work Orders #### Create a work order {#create-work-order} - **Effect** (universal, both systems) — a work order created with **no** billing-work-order reference becomes its own BWO (standalone); one created **with** a reference becomes a Sub-WO of that BWO. Either way it's ready to carry lines and recordings. - **(Jira) Just-in-time + auto-BWO.** This is how Jira *derives* that reference. Work orders are created only when needed — triggered by a recording against a work item, or a budget assigned to a work item. On creation the hierarchy is walked up (task → story → epic) to the first parent matching the configured "Billing Work Order Type": that parent becomes the BWO; if no work item above matches, the work order becomes its own BWO. (Other systems supply the reference directly rather than deriving it this way.) - **(Jira) Existing work orders preserve their BWO.** Auto-BWO assignment runs only at creation. The work-item hierarchy keeps arriving on later syncs, but for a work order that already exists it is **not** re-applied — so an automatic process can't clobber a BWO a user set manually. After creation, only an explicit BWO change moves the BWO. #### Change the Billing Work Order {#change-bwo} *(change which WO this one bills through)* - **Guard (always)** — three independent blocks; **all** must be clear: 1. **Not a BWO in use.** A work order serving as a BWO for others can't change its BWO (it would orphan its Sub-WOs). 2. **Target is a real BWO.** The target must be its own BWO, preserving the [Flat Hierarchy](#flat-hierarchy). 3. **Not locked by recordings** ([Structural Lock](#structural-lock)) — blocked once a Project-mode WO has any recording, or an Open-mode WO has a Released/Posted recording. Changing the BWO has two starting points, which differ in how the lines are handled: - **Moving a Sub-WO to a different BWO.** Its lines aren't its own — they reference the old BWO's master lines ([BWO Lines](#bwo-lines)) — so the move drops them all. A line that carries a recording can't be dropped ([Delete a work order line](#delete-line)), so the move is *additionally* blocked while **any** of its lines has a recording, even an Open one. - **Demoting a standalone BWO to a Sub-WO.** Its lines are its own masters: recording-free lines are deleted, recording-bearing lines are kept. - **Effect** (either way) — Customer, Project, and Budget Type are inherited from the new BWO ([BWO Ownership](#bwo-ownership)); the inherited Project change behaves like [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project). Non-posted recordings now bill through the new BWO. #### Change Customer or Project {#change-customer-project} - **Guard** — two independent blocks: 1. **Not locked by recordings** ([Structural Lock](#structural-lock)) — Budget Type Project: blocked once **any** recording exists in the billing group (no automatic retargeting in Project mode yet — recordings must be moved or deleted first). Open budget: never blocked — Customer/Project may be set, cleared, or changed at any time. 2. **Project needs a Sell-to Customer.** A Project can only be selected if it has one (otherwise it can't be invoiced). - **Effect** - On a BWO, the change cascades to all Sub-WOs ([BWO Ownership](#bwo-ownership)); Sub-WO Customer/Project are read-only and can only change this way (or by [changing the Sub-WO's BWO](#change-bwo)). - Changing/clearing the Customer clears the Project; if the new Customer has exactly one active Project (Status ≠ Complete), it is selected automatically. Selecting a Project sets the Customer; clearing the Customer clears the Project. - Changing the Project updates recordings **without** a PT to the new Project automatically. Recordings **with** a PT would lose their PT/PPL/Activity, so the user must fix them; until then they can't be released or invoiced, and the old WOL they still reference can't be deleted (it shows **red**). - **Why** — in Project mode the recordings are bound to the WO's Customer/Project, so any change would instantly invalidate them; in Open mode no such binding exists, so the change is always safe and is the supported way to correct an error. #### Change Budget Type {#change-budget-type} - **Guard** - **Open → Project:** a Customer and Project must be set, and every existing recording must have a PPL matching a work order line. If some don't, the system offers to auto-create the missing lines; declining aborts the change. - **Project → Open:** always allowed — relaxing constraints can't invalidate data. - **Effect** — on a BWO, the Budget Type cascades to all Sub-WOs ([BWO Ownership](#bwo-ownership)); a Sub-WO can't change its Budget Type directly. #### Delete a work order {#delete-work-order} - **Guard** — two independent blocks; **both** must be clear: 1. **No dependent Sub-WOs.** A work order serving as the BWO for others can't be deleted (it would orphan them) — first delete or reassign all Sub-WOs. 2. **Not locked by recordings** ([Structural Lock](#structural-lock)) — Project budget: blocked once any recording exists; Open budget: blocked only while Released/Posted recordings exist (deletable when only Open recordings exist). - **Why** — deleting a work order with committed recordings would lose approved, financially recorded work. ### 5.2 Work Order Lines #### Add a work order line (on a BWO) {#add-line} - **Guard** — two independent blocks: 1. **On a BWO only.** Lines are created on the BWO, never directly on a Sub-WO ([BWO Lines](#bwo-lines)). 2. **PPL unique per work order.** A PPL may appear in at most one line per work order; adding one already present is rejected (prevents double-counting and the need to pick a line when recording). - **Effect** — the line now exists on the BWO, available to assign to Sub-WOs as a separate, deliberate step ([BWO Lines](#bwo-lines)). #### Assign a line to a Sub-WO {#assign-line} - **Guard** — only lines that exist on the parent BWO can be selected ("Get Work Order Line"); you cannot create a new line directly on a Sub-WO ([BWO Lines](#bwo-lines)). - **Effect** — the Sub-WO line references its BWO master line. #### Delete a work order line {#delete-line} - **Guard** — blocked while **any** time recording references `(WO, PPL)` — *any* status, *either* budget type ([Structural Lock](#structural-lock), strict form). An Additional Service line is protected the same way. - **Effect** - Deleting a **BWO** line cascades: the matching lines on all Sub-WOs are deleted too (Sub-WOs must not keep phantom references to removed budget). - Deleting a **Sub-WO** line removes it from that Sub-WO only; it stays on the BWO and other Sub-WOs. - **Why** — an Open recording can't be released without its line; Released/Posted recordings carry financial history that must be preserved. (Stricter than [Delete a work order](#delete-work-order), which allows an Open-only Open-budget WO to be deleted.) ### 5.3 Time Recordings #### Record time (create) {#record-time} - **Guard / behaviour by [Budget Type](#budget-type)** - **Open:** the recording must use the WO's Customer and Project (if filled). If the WO has no Customer/Project, the first recording carrying them sets them on the WO, and other empty recordings are auto-completed. A recording whose PPL has no line auto-creates the line. - **Project:** the recording must use a PT/PPL that matches an existing work order line, or it can't be saved. If a Sub-WO has **any** line of its own, the recording must use one of those; only a Sub-WO with **no** lines of its own falls back to the BWO's lines. - **Effect** - Selecting a PT pre-fills the recording's Activity from the matching line's default (still changeable). - An Additional Service may be selected whether or not its line exists yet — saving auto-creates the line (both budget types). - **(Jira / Azure DevOps)** Customer/Project (and more) can be assigned from Space, Organization, Customer, Asset; a recording using such an assignment creates the WO with the assigned information. - **Why** — Open mode minimises setup for reactive work; Project mode guarantees all time is trackable against pre-allocated budget. Customer/Project carry financial implications (Time & Travel Model, Bill-to, surcharges), so a recording can't deviate from the WO's once set. #### Change the work order on a recording {#change-wo-on-recording} - **To a Project-budget WO** — Customer/Project update to match; the existing PT/PPL/Activity are validated against the new WO's lines and cleared if invalid (the user must pick valid ones). - **To an Open-budget WO** — Customer/Project update only if they were empty; if the new WO has exactly one line and the recording's PT/PPL/Activity are empty, they're auto-filled. #### Clear the work order on a recording {#clear-wo} - **Effect** — Customer, Project, PT, PPL, and Activity are all preserved; only the work order association is removed (the work performed is still valid). #### Release {#release} - **Guard** — a recording with a WO and PPL can't be released unless a matching work order line exists; releasing without one errors. (In Open mode the line was already auto-created when the recording was saved, so this is a safety net.) A Sub-WO without its own line releases through the BWO's lines. - **Effect** — status Open → Released; the billable duration is added to "Quantity to Invoice" — on the **work order line** when the recording has a work order, or on the **PPL (Budget)** when it has none — with Time & Travel model rounding applied. - **Why** — release is the approval step; the Quantity to Invoice has to live on a line. #### Post {#post} - **Effect** — status Released → Posted, and the financial records are written: - Project Ledger Entries (Usage) are created, saving the WO and BWO No. - PPLs (Billable) are created/updated; with Work Order Posting on, one PPL (Billable) is created **per BWO and PPL (Budget)** — multiple Sub-WOs on the same PPL under one BWO aggregate into it (billing aggregates at the BWO level). - Quantity to Invoice transfers from the work order lines / PPL (Budget) to the PPL (Billable); Sales Order lines update if applicable. - **After posting** — the [Structural Lock](#structural-lock) holds the structure: no BWO change, no Customer/Project change on a Project-budget BWO, no deletion of lines used by posted recordings. (Open-budget Customer/Project stays changeable; posted recordings keep their Project and their ledger entries are unaffected.) These records are corrected by [Cancel](#cancel), never by mutating what they point to. #### Cancel (a posted recording) {#cancel} - **Effect** — negative Project Ledger Entries (Usage) and negative PPL (Billable) entries are created (from the positive ones); the recording returns to Open and the cancelled quantity becomes available budget again. Keeps a complete audit trail. ## 6. Service Billing Type {#service-billing-type} The Service Billing Type on a PPL determines how its budget is consumed and invoiced. | | Time & Material | Budget | Fixed Price | |---|---|---|---| | Reserved Quantity vs budget | may exceed; not updated by posting | may exceed; not updated by posting | may exceed; not updated by posting | | Invoicing ceiling | none — all billable time is invoiced | PPL (Budget) quantity is a hard cap | the PPL (Budget) quantity, invoiced in full on completion | | Posting beyond budget | PPL (Budget) auto-increases; Sales lines follow | allowed, but not invoiced past the cap | allowed, but only the budgeted quantity is invoiced | | Quantity to Invoice | calculated on release (sum of billable duration) | up to the cap | whole quantity on completion; no partial invoicing | - **Time & Material** — ongoing work; the customer pays for actual effort. - **Budget** — a maximum cap; the customer pays up to a limit. - **Fixed Price** — deliverable-based; a fixed amount regardless of effort, invoiced on completion. Recordings track effort but don't drive invoicing quantity. ## 7. Budget Reservation {#budget-reservation} A work order line can reserve budget exclusively for its work order. - An empty Reserved Quantity means the work order shares the budget with all others (e.g. multiple work orders for workshops/trainings); releasing recordings then locks budget via Quantity to Invoice, first come first served. - A set Reserved Quantity is locked to the work order and limited by the selected quantity — except Time & Material, which may grow (Software Changes, Change Requests). - The Reserved Quantity is invoiced by the work order that reserved it. - Reserved Quantities may sum to more than the actual budget; the Available Quantity is then highlighted **red**. ## 8. Quick Reference ### Valid BWO configurations {#valid-bwo-configurations} | WO-A | A's BWO | WO-B | B's BWO | Valid? | |------|---------|------|---------|--------| | WO-01 | WO-01 | - | - | Yes (standalone) | | WO-01 | WO-02 | WO-02 | WO-02 | Yes (simple hierarchy) | | WO-01 | WO-02 | WO-03 | WO-02 | Yes (siblings under one BWO) | | WO-01 | WO-02 | WO-02 | WO-03 | **No** (nesting) | | WO-01 | WO-02 | WO-02 | WO-01 | **No** (loop) | ### Budget Type comparison | Aspect | Open | Project | |--------|------|---------| | PPL selection when recording | any valid PPL of the Project | only PPLs that have a work order line | | Auto-create work order lines | Yes | No | | Delete WOL — no recording | Yes | Yes | | Delete WOL — Open recording | **No** | **No** | | Delete WOL — Released/Posted | No | No | WOL deletion is blocked by **any** recording in both modes (the strict form of the [Structural Lock](#structural-lock)). ### Structural Lock at a glance What recordings block, by budget type and the most advanced recording status present (whole billing group). Governs: [Change BWO](#change-bwo), [Change Customer/Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project), [Delete WO](#delete-work-order), [Delete WOL](#delete-line). | Time recording status | Open budget | Project budget | |------------------------|-------------|----------------| | None | allowed | allowed | | Open | allowed¹ | **blocked** | | Released / Posted | **blocked** | **blocked** | ¹ Except [Delete a work order line](#delete-line), blocked by **any** recording in both modes. ### Time Recording status transitions ``` ┌─────────────────────────────────┐ │ │ ▼ │ [Open] ──release──► [Released] ──post──► [Posted] ▲ │ │ │ │ │ └────────reopen───────┘ │ │ │ └─────────────cancel─────────────────────┘ ``` ### Entity relationships ``` Customer (1) ◄─────── (N) Project (1) ◄─────── (N) Project Task │ ▼ Project Planning Line │ ▼ Work Order (N) ◄────────────────────────────────► Work Order Line │ ▼ Billing Work Order (self or other WO) ``` ## 9. Planned Future Not yet enforced. **Milestone-based invoicing** *(needs further product discovery)* — recordings can be posted without triggering automatic invoicing; invoicing is held until a milestone condition is met (e.g. work order marked complete); work in progress (WIP) is tracked during the hold. ## Addendum: Synchronization {#sync} Mechanism, not a business rule — but it shapes how the rules above must be emitted across systems, so it's recorded here. Work order data synchronizes between systems (Connect, BC, Jira). A change is **not** one atomic transaction: the originating system emits it as a sequence of single-field operations, each carrying the entity's full state, and the receiver runs its own business-rule checks on each operation as it arrives. Two properties keep that safe: - **Ordered replay.** Because the receiver acts on each operation in turn, order matters and every intermediate state must be valid on its own. The originator must sequence operations so the receiver's re-derived state matches with nothing of its own left to emit. Examples: lines must be created *before* Budget Type changes Open → Project; a Customer must be set before a Project; a WOL is deleted only *after* its recordings have moved to the new Project. - **Single origin.** A change a system *received and applied* — and any further change its own logic produced while applying it — must never be emitted back. The receiver accepts the incoming change as authoritative by design and applies it without reflecting it to the sender. This is exactly where re-running local logic on receive is dangerous: a side effect of applying a received change can look like a fresh local change and get re-emitted — that reflected change is an *echo*, and a defect. The one legitimate back-flow is BC stamping the WO No. it assigned onto an inbound work order create — that No. genuinely originates in BC, so emitting it *is* this rule, not an exception. **Both systems keep enforcing their business-rule *checks* on receive** — a received change must still be valid on arrival — **but they do not replay side effects that modify data.** The cascades, prunes, and auto-created lines a change implies are computed by the originating system and arrive as their own operations; re-deriving those data mutations on the receiver is exactly what creates an echo. **What syncs:** synchronization is driven by tracked data changes, not a curated list of triggers — every create, update, or delete of a synced entity is captured and propagated. Connect → BC is audit-driven (an ordered SyncService); BC → Connect goes through a tracking table. (In Jira a work item only becomes a work order once it is touched, but that is Jira's just-in-time creation — see [Create a work order](#create-work-order) — not the Connect↔BC sync trigger.) ## Appendix: Legacy rule-number index {#appendix-legacy-rule-number-index} > **Historic reference only — do not use these numbers in new work.** Earlier versions > of this document numbered rules `X.Y`. That catalog has been replaced by the named > [invariants](#invariants) and [operations](#operations). This table maps each old > number to where its content now lives, so old citations (in other documents or code) > can be found and migrated. New cross-references should point at the invariant or > operation by name. | Old rule | Now in | |----------|--------| | 4.1 Two-level max | [Flat Hierarchy](#flat-hierarchy) | | 4.2 No loops | [Flat Hierarchy](#flat-hierarchy) | | 4.3 No nesting | [Flat Hierarchy](#flat-hierarchy) | | 4.4 BWO change gated | [Change the Billing Work Order](#change-bwo) | | 4.5 Valid configurations | [Valid BWO configurations](#valid-bwo-configurations) | | 5.1 Sub inherits Customer/Project | [BWO Ownership](#bwo-ownership) | | 5.2 Sub can't override | [BWO Ownership](#bwo-ownership) · [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project) | | 5.3 Cascade to Sub-WOs | [BWO Ownership](#bwo-ownership) · [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project) | | 5.4 Customer/Project gated | [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project) | | 5.5 Customer change clears Project | [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project) | | 5.6 Project requires Customer | [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project) | | 5.7 Projects without Customers | [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project) | | 5.8 Changing Project / recordings | [Change Customer or Project](/docs/pb/professional-services/work-order-business-rules#change-customer-project) | | 6.1 BWO holds master set | [BWO Lines](#bwo-lines) | | 6.2 Create doesn't copy | [Add a work order line](#add-line) | | 6.3 Delete BWO line cascades | [Delete a work order line](#delete-line) | | 6.4 Sub selects from BWO lines | [Assign a line to a Sub-WO](#assign-line) | | 6.5 Delete Sub-WO line | [Delete a work order line](#delete-line) | | 6.6 PPL once per WO | [Add a work order line](#add-line) | | 6.7 WOL deletion gated | [Delete a work order line](#delete-line) | | 6.8 Additional Services auto-create lines | [Record time](#record-time) | | 7.1 Open behaviour | [Budget Type](#budget-type) · [Record time](#record-time) | | 7.2 Project behaviour | [Budget Type](#budget-type) · [Record time](#record-time) | | 7.3 Open → Project | [Change Budget Type](#change-budget-type) | | 7.4 Project → Open | [Change Budget Type](#change-budget-type) | | 7.5 Budget Type cascades | [BWO Ownership](#bwo-ownership) · [Change Budget Type](#change-budget-type) | | 7.6 Sub can't change Budget Type | [BWO Ownership](#bwo-ownership) · [Change Budget Type](#change-budget-type) | | 8.1 Status lifecycle | [§3 State](#state) | | 8.2 Project requires matching line | [Record time](#record-time) | | 8.3 Project Sub-WO without lines | [Record time](#record-time) | | 8.4 Open auto-completes Customer/Project | [Record time](#record-time) | | 8.5 Open limits to WO Customer/Project | [Record time](#record-time) | | 8.6 Open auto-creates lines | [Record time](#record-time) | | 8.7 Change WO on recording → Project | [Change the work order on a recording](#change-wo-on-recording) | | 8.8 Change WO on recording → Open | [Change the work order on a recording](#change-wo-on-recording) | | 8.9 Clear WO preserves fields | [Clear the work order on a recording](#clear-wo) | | 8.10 Activity defaults from line | [Record time](#record-time) | | 8.11 Released/Posted blocks changes | [Structural Lock](#structural-lock) | | 9 Budget Reservation | [§7 Budget Reservation](#budget-reservation) | | 10.1 Time & Material | [§6 Service Billing Type](#service-billing-type) | | 10.2 Budget | [§6 Service Billing Type](#service-billing-type) | | 10.3 Fixed Price | [§6 Service Billing Type](#service-billing-type) | | 11.1 Just-in-time creation | [Create a work order](#create-work-order) | | 11.2 Automatic BWO assignment | [Create a work order](#create-work-order) | | 11.3 Existing WOs preserve BWO | [Create a work order](#create-work-order) | | 11.4 BWO with Sub-WOs can't be deleted | [Delete a work order](#delete-work-order) | | 11.5 WO deletion gated | [Delete a work order](#delete-work-order) | | 12.1 What releasing does | [Release](#release) | | 12.2 Line required for release | [Release](#release) | | 12.3 What posting does | [Post](#post) | | 12.4 PPL (Billable) per BWO | [Post](#post) | | 12.5 Posting locks the hierarchy | [Post](#post) · [Structural Lock](#structural-lock) | | 12.6 Cancellation reopens recordings | [Cancel](#cancel) | | 13.1 Operations sent separately | [Sync](#sync) | | 13.2 Intermediate states valid | [Sync](#sync) | | 13.3 Sync triggers | [Sync](#sync) | | 13.4 Order of operations | [Sync](#sync) | --- ## Work Order Lines Update # Migration Guide: Work Order Lines Update (2026) ## Overview **DYCE Project Billing** is undergoing a structural evolution. To support granular budget allocation and seamless Jira integration, the data structure is moving from Work Order Header fields to **Work Order Lines**. This change makes it possible to assign multiple budget lines to a single work order, which enables task-oriented budgets instead of rough, project-based budgeting. **Key Benefits** * **Multi-Budget Allocation:** Assign multiple project tasks and planning lines to a single work order. * **Jira Integration:** Time Tracking can be used directly in Jira. Time recordings, work orders, and work order lines are synchronized with Business Central. * **Jira Structure:** Aggregate a nested Jira hierarchy in so-called *Billing Work Orders* and connected Sub-Work Orders to simplify invoicing. * **Task-Oriented Approval:** Release and invoice time recordings based on specific tasks (work orders) rather than considering the entire project task. * **Status and period-based invoicing:** Time recordings of work orders can be released based on the status (e.g., change request, software changes) or at the end of the month (e.g., workshops, training), which allows for invoicing them as soon as possible. :::warning **Mandatory Dependency: DYCE Time Tracking** *This restriction will be enforced in June 2026.* **Reason:** Work orders are functionally dependent on **DYCE Time Tracking**. A work order cannot perform its primary purpose of capturing and invoicing time recordings unless the following condition is met: * **Time Tracking Enabled:** "Time Tracking must be enabled in the [Feature Management](/docs/web/administration/setup-web.md#feature-management) page in the Administration area of DYCE Connect. If this setting is deactivated, it is technically not possible to create time recordings for work orders. **Why this matters:** The work order structure has been specifically developed to connect external systems such as Jira and Azure DevOps via DYCE Time Tracking. If Time Tracking is not used, DYCE does not support time recordings in connection with work orders. ::: ## Project Billing 2026.4 The most significant change is structural. Previously, details such as the Project Task or Project Planning Line were stored directly in the header of the work order. This change allows for an impressive innovation. * The **2-level hierarchy** enables the definition of a Billing Work Order, which is used to release and invoice the time recordings of the Sub-Work Orders. * **Usability Improvement:** This eliminates the need for complex multi-level nesting in the releasing and invoicing process, while allowing users to organize work naturally (e.g., individual tasks rolling up to a Story or Epic for invoicing). * **Billing Consistency:** A Sub-WO automatically inherits its Customer and Project from the Billing Work Order, ensuring 100% billing consistency across a project team without manual data entry. * **Time Recording Consistency:** Time recordings have to use the customer and project of the work order, regardless of the *Budget Type*, to ensure the time recordings of a work order contribute to the same project. * Refined Budget Types **Open** and **Project** * **"Open" Mode (High Flexibility):** Perfect for reactive work (e.g. support tickets in Jira Service Management). If a user creates a time recording in a new task, the system auto-creates the work order and the work order line. It even auto-fills the Customer/Project based on the first entry. Everything is transferred to Business Central to be released and posted, without any manual effort. * **"Project" Mode (High Control):** Designed for fixed-budget implementations (e.g. sales order). Users are restricted to selecting only pre-defined work order lines, preventing accidental overruns or misallocations at the point of creating time recordings. * Advanced financial and budget guardrails * **Structural Locking:** Once a time recording is released or posted, the system "freezes" the structural metadata (Customer, Project, BWO). This prevents the "shifting sand" problem, where an invoice target is changed after the work has been approved. * **Budget Reservation:** Work order lines can now exclusively reserve quantities. If the budget is shared, it uses “first-come, first-served,” but for specific change requests, the budget can be "locked" to that specific work order. * **Visual Indicators:** If the sum of reserved quantities exceeds the actual project budget, the system highlights the values in red, providing immediate visual feedback to project managers. * Seamless Billing Logic (Service Billing Types) The logic behind how time becomes money is now more granular: * **Time & Material:** Automatically scales the budget ceiling as work progresses. * **Budget (Capped):** Allows effort tracking beyond the limit but strictly stops invoicing once the ceiling is reached. * **Fixed Price:** Effort is tracked for internal cost analysis, but the invoice is driven by completion, not hourly duration. [More information about work order business logic](/docs/pb/professional-services/work-order-business-rules.md) :::info Available in May Please note that these features will be available once the update has been completed and the data upgrade has been performed in May. Project Billing will be limited to one work order line per work order with Budget Type *Project* to be compatible with Connect, until all upgrade steps are completed (in the future). Work order lines in work order with Budget Type *Open* are not allowed. Work order posting is locked until the Connect Backend is ready. ::: ## Update Process The new versions of DYCE Project Billing and DYCE Sync have been released on AppSource (version 2026.4.0.0). :::info Verify Connect Version On the **DYCE Synchronization Setup** page, you can use the Page Inspector to check the **Backend Version**. The Backend Version represents the version currently used by DYCE Connect. This is helpful for diagnosing the current status of all involved components: * **Backend Version = 1:** DYCE Connect has not been updated yet and does not support Work Order lines. * **Backend Version = 2:** DYCE Connect has been updated by Singhammer and now supports Work Order lines. ::: ### Stage 1: * **ToDo:** * The update of the Sync app and Project Billing should be completed by **04.05.2026** * Start with the Sync app. It should update Project Billing automatically. * If the upgrade did not trigger, it can be run manually with the action **Create Work Order Lines from Header (Stage 1 Migration)** in **Project Setup**. If it did run, the action is disabled. * Please check the field **Migration Stage** in **Project Setup**. It should display **Header to Line Done**. * Please check that the Sync is still running. * **Result:** * After the update, Project Billing (2026.4) works with work order lines. * The Sync app 2026.4. translates the work order lines in BC to the header fields in Connect. * DYCE Connect (Time Tracking) is still working with the fields (project task and planning line) in the header. If the project task has been saved in the work order but no planning line is selected, the work order line will be created without a planning line. The data upgrade will be triggered automatically. * The logic of the work order will remain the same in this stage. * **Data** * *Projekt Ledger Entries* has new fields *Work Order No.*, *Billing Work Order No.*. They are filled during the update with the the values of the time recording in Projekt Ledger Entries Usage. * For Work Orders with Budget Type *Project* *Work Order Lines* are created based on the project task and planning line in the header. * *Billing Work Order No.* in the time recording is updated. :::warning Update Sync app Project Billing Project Billing will check the Sync app when updating. If the Sync has not been updated, the data upgrade will not be triggered automatically. If the Sync is not updated, it will not be able to transfer records between DYCE Connect and BC. ::: ### Project Billing without Sync: If the Sync app is not installed, the data migration will not be triggered automatically. * **ToDo:** * It can be run manually with the action **Create Work Order Lines (Full Migration)** in **Project Setup**. If it did run the action is disabled. * **Result:** * Please note that it will not be possible to create time recordings for work orders if Time Tracking is disabled (or not Onboarded). Please contact your partner if you are using a work order, but do not use Time Tracking. * The field **Migration Stage** in **Project Setup** should display **Upgrade Done**. Please check. * **Data** * *Projekt Ledger Entries* has new fields *Work Order No.*, *Billing Work Order No.*. They are filled with the the values of the time recording in Projekt Ledger Entries Usage. * *Billing Work Order No.* in the time recording is updated. * For Work Orders with Budget Type *Project* *Work Order Lines* are created based on the project task and planning line in the header. * *Work Order Lines* are created based on time recordings with a Work Order and project planning line. :::note Temporary Restrictions Until the 3-stage rollout is complete, there are two key points to keep in mind for your active projects: * **Work Order Posting:** The field in **Project Setup** is temporarily locked until the Connect Backend (Stage 2) is ready. This prevents synchronization errors during the transition. * **Single-Line Limit:** In the first phase (Stage 1), each work order with Budget Type *Project* is limited to a single budget line. work orders with Budget Type *Open* cannot have any work order lines. This ensures compatibility with the older Connect backend. The full "Multi-Line" capability will be unlocked automatically during Stage 2. ::: ### Stage 2: * **Todo:** * There is nothing to do on your end. Singhammer will update Connect to work with work order lines in mid-May. * **Result:** * The temporary restrictions are lifted. * [Work Order Business Rules](/docs/pb/professional-services/work-order-business-rules.md) are applied for working with work orders, from now on. ### Stage 3: * **Todo:** * The field **Migration Stage** in **Project Setup** should display **Upgrade Done**. Please check. * If the data migration is not automatically triggered, it can be run manually with the action **Create Work Order Lines from Time Recordings (Stage 2 Migration)** in **Project Setup**. If it did run, the action is disabled. * **Result:** * The migration did run automatically. The first Heartbeat sent by Connect will trigger the data migration in Project Billing (BC) 1. The migration will send all existing work order lines from BC to Connect. This is done so that the IDs of the lines are the same in BC and Connect. 2. Work order lines will be created for all time recordings with a project planning line and work order (both Budget Types). If the work order does not have a project, no work order lines will be created. 3. The newly created work order lines will automatically be synced to Connect. * **Data** * *Work Order Lines* are created based on time recordings with a Work Order and project planning line. ## Technical Version Constellations |Constellation |Project Billing |Sync App |Connect Backend |Migration Stage| Note| |:--|:--|:--|:--|:--|:--| |Legacy|2026.3. or older|2026.3. or older|2026.3. or older|Field on Project Setup not added yet|Baseline version before the update| |Incomplete Stage 1|2026.4. or newer|2026.3. or older|2026.3. or older|None|Update the Sync app **NOW**. It can no longer communicate with Project Billing.| |Complete Stage 1 - April|2026.4. or newer|2026.4. or newer|2026.3. or older|Header to Line Done|If the Migration Status is not *Header to Line Done* contact your partner.| |Stage 2 - May|2026.4. or newer|2026.4. or newer|2026.4. or newer|Upgrade Done|If the Migration Status is not *Upgrade Done* contact your partner.| |Standalone|2026.4. or newer|not installed|n/a|None|The data upgrade will not run automatically.| ### Legacy DYCE Project Billing is installed, and the April 2026.4 version has not been installed yet. If the DYCE Sync app is installed, the April 2026.4 version has not been installed yet. Please check the apps in the [Business Central Admin Center](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/tenant-admin-center-manage-apps) if you are uncertain, which apps are installed or which version they have. ### Incomplete Stage 1 DYCE Project Billing has been updated to version 2026.4, but the Sync app has not been updated. :::warning **The Sync can no longer manage the communication between Project Billing and Time Tracking.** Update the Sync app immediately to avoid potential data loss. If you cannot update it in the Admin Center, turn off the *Automatic Synchronization* in **DYCE Synchronization Setup** and contact your partner. ::: ### Complete Stage 1 - April DYCE Project Billing and Sync app is installed and updated to version 2026.4. The field **Migration Stage** in **Project Setup** displays **Header to Line Done**. ### Target Release - May DYCE Project Billing and Sync app is installed and updated to version 2026.4. The Connect Backend (Time Tracking and Project & Resource Planning) has been updated. The field **Migration Stage** in **Project Setup** should display **Upgrade Done**. ### Standalone DYCE Project Billing is installed, but the Sync app is not. The data migration has to be triggered manually. The action **Create Work Order Lines (Full Migration)** in **Project Setup** runs the data migration. If it has already run, the action will be disabled. Please note that it will not be possible to create time recordings for work orders if Time Tracking is disabled (or not onboarded). Please contact your partner if you are using a work order, but do not use Time Tracking. The field **Migration Stage** in **Project Setup** should display **Upgrade Done**. --- ## Work Order Work Orders form the interface between planning, project management, and billing of services. They enable detailed work in Business Central and the seamless integration of complex, hierarchical task structures (such as Atlassian Jira and Azure DevOps) into precise and customer-friendly invoicing. A Work Order in DYCE serves as a central document that organizes the entire lifecycle of a task and answers the fundamental questions of *What*, *Who*, *For Whom*, as well as detailed information such as estimated effort, type, and budget assignment. Work Orders can be created and managed in external systems such as Atlassian Jira and Azure DevOps. This section of the documentation focuses on working within Project Billing, Business Central, and DYCE Connect in the broader sense. Work Orders can also be created directly from a Sales Order in Business Central. In this flow, the Work Order is linked to the originating Sales Order and opened in a pre-filtered Sales Order context. See [Creating Work Orders from Sales Orders](/docs/pb/professional-services/creating-work-orders-from-sales-orders) for the step-by-step process. Typical examples of a Work Order: * Conducting a workshop or training session * Conception and development of a user story * Recording and resolving a bug * Installation of hardware or software * Performing maintenance work How Work Orders are used depends heavily on the intended process. The general recommendation is to work as broadly as possible and as granularly as necessary, in order to keep the overhead from administration and management low. The granularity of tasks in implementation projects, for example, depends heavily on the process. Should workshops be one Work Order with a Work Order Event for each appointment, or should one Work Order per workshop be required? When designing the process, consideration should be given to how tasks should be planned, divided, and above all billed. ## Structure of a Work Order {#properties} Work Orders are versatile and flexible. The following describes configuration options and how they can be used for different processes. The Work Order card is divided into several areas. All contain relevant information for the execution and billing of a Work Order. ### 1. Details and Hierarchy (*For Whom*) These details define *For Whom* the work is performed and how it is organized. A service is always provided by a resource for a customer and a project (even for internal activities). * **Title:** A short, concise headline. * **Customer Name:** Name of the customer for whom the service is performed (sold to). * **Project Description:** The assignment to a project, in which the budgets and services are summarized. Time Recordings for the Work Order must use the project. * **Budget Type:** Indicates the degree of freedom for Time Recordings with the options **Open** (default) and **Project**. * *Open:* The Budget Type allows maximum flexibility. If no customer or project is entered in the Work Order (e.g., for new tickets), these are filled by the first Time Recording with a customer and project. The Budget Type allows the user to freely select project tasks and project planning lines in the Time Recording. Work Order Lines are automatically created to facilitate approval and billing. This option is particularly useful for tickets and collectors where the type of service/Time Recording should not be restricted. * *Project:* Restricts the selection in the Time Recording to the project tasks and project planning lines used in the budget lines. This option is used when the budget to be used is determined by a project manager (e.g., workshops, customer-specific developments in connection with an order). * **Billing Work Order No.:** Tools such as Jira or Azure DevOps use complex hierarchies (Feature >> User Story >> Task). Project Billing in Business Central consolidates these into two levels to simplify billing: * *Billing Work Order:* The Work Order known to the customer typically serves as the Billing Work Order. During approval and billing, the Time Recordings are aggregated to this Work Order. This means that the Time Recordings of the Sub-Work Orders are displayed in the Billing Work Order during approval. * *Sub-Work Order:* All Work Orders that use a different Work Order No. in *Billing Work Order No.* instead of themselves. They serve internal organization and subdivision (e.g., development and code review for a customer development). Sub-Work Orders are not printed separately in invoices. * *Assignment:* A Work Order is assigned to another as a Sub-Work Order by selecting the Billing Work Order in *Billing Work Order No.* in the Sub-Work Order. * *IsBilling (Billing Work Order):* If the Work Order uses itself as the Billing Work Order, the *IsBilling* flag = Yes. Otherwise it is No. The flag can be used via the page inspection to filter. In the Work Order list, it can be filtered by this flag. ### 2. Documentation and Description (*What*) These details define the *What* of the task. This primarily includes various types of texts (e.g., title and description) that describe the task. * **Description:** A detailed description of the work to be done or the problem statement. * **Internal Notes:** Notes for internal use, visible only to users. Hints, checklists, and other information that do not contribute to the description of the matter but offer situational added value are preferably stored here. For example, changes requested by the customer can be recorded and quickly found if needed. * **Solution:** Description of the solution, measures taken, etc. The description of the solution should correspond to the actually implemented solution. Otherwise, it will be difficult to trace later. :::info The working method of Jira and Azure DevOps is partly based on hierarchy. Working with multiple levels in Business Central (without Jira or Azure DevOps) is possible, but potentially results in higher organizational overhead. ::: ### 3. Planning and Effort (*When & Who*) These properties define the *When*, *By Whom*, and the expected effort. A Work Order can be provided with a concrete deployment schedule (**Events**), which function similarly to appointments: a person completes a task at a specific point in time. * **Resource Name:** The employee responsible for execution. To ensure clear accountability, only one resource can be assigned. * **Events:** One or more appointments for execution. Events are opened via the *Events* menu item in the Work Order. Only resources with the *Plannable* flag can be planned. * **Original Estimate:** The estimated time required (in hours or days). * **Remaining Estimate:** The remaining time required (in hours or days). * **Completed:** The current status of the Work Order. The *Completed* status can be set automatically and used as a filter in Project Billing Approval. * **Locked:** Prevents the creation of new Time Recordings for the Work Order. * **Guardrail:** Users cannot create new Time Recordings for this Work Order. * **Flexibility:** Existing Time Recordings can still be modified, approved, and posted. This is ideal for phases where the work is finished but the recorded times still need to be cleaned up. * **Location:** The physical or virtual location where the work is performed. * **Type:** A classification of the Work Order (e.g., *Story, Task, Bug, Maintenance, Installation, Support Request*). Distinguishing Work Orders by type provides the opportunity to differentiate them in planning and billing. We recommend at least distinguishing between Work Orders that are approved and invoiced periodically at month-end and those approved and invoiced upon completion. During approval, filtering by type makes the process more efficient. * **Area:** A classification of the Work Order. * **Sprint:** Specification of the sprint. :::tip Display Format Quantity In Project Setup on the Work Order tab, the display format for **Original Estimate** and **Remaining Estimate** is configured. * **Hour:** Entered numbers are interpreted and displayed as hours. * **Day:** Entered numbers are interpreted and displayed as days. * **Dynamic:** Displays hours and automatically switches to days when the quantity exceeds hours per day. The input supports the abbreviations **h** and **d**. ::: :::info Assigning One vs. Multiple Resources Only one resource is always assigned to a Work Order. This resource bears responsibility for the task. If multiple people were assigned, it would not be clear who is responsible. Furthermore, Jira and Azure DevOps also only support one assigned resource by default. Additional resources can be scheduled for a Work Order over time via [Work Order Events](#work-order-events). ::: ### 4. Work Order Lines Work Order Lines allow flexible and easy work on tasks, while automatically ensuring in the background that every minute worked is immediately assigned to the correct budget and billed as quickly as possible. They link the Work Order to project planning lines of the line type *Budget* and define how Time Recordings are recorded and billed. The fundamental rules can be read [here](/docs/pb/professional-services/work-order-business-rules.md). #### 4.1. Creating Work Order Lines {#41-creating-work-order-lines} Work Order Lines are created manually using the **Add Lines from Project Planning Lines** action on the *Lines* tab of the Work Order card. This opens the **Create Lines** page. Select the desired project planning lines and confirm with *Ok*. Without a project or a budget project planning line in the project, no Work Order Line can be created. Project Planning Lines can be created directly from a Customer Subscription Contract, see [Creating Project Planning Lines from Contracts](/docs/pb/professional-services/project-planning-lines.md). If the Work Order was created from a Sales Order, the line selection is still based on project planning lines, but planning lines linked to that Sales Order are highlighted to simplify selection. See [Creating Work Orders from Sales Orders](/docs/pb/professional-services/creating-work-orders-from-sales-orders). * **Multi-Line Selection:** The *Create Lines* page allows the selection of multiple project planning lines and the creation of Work Order Lines. * **No Duplicate Project Planning Lines:** The same *Budget* project planning line cannot be created twice as a Work Order Line in one Work Order. This simplifies time recording because it is sufficient to select a Work Order and planning line in the Time Recording to identify the Work Order Line. * **Automatically Created Work Order Lines:** In Time Recordings with a Work Order (Budget Type = Open), the project tasks and planning lines for which a Work Order Line exists are highlighted in the lookup. If the user selects a project task and planning line for which no Work Order Line exists, one is automatically created. The *Open* Budget Type is particularly useful for reactive tasks. In a new ticket, no Work Order Lines may have been created yet. Because they are created directly when Time Recordings are created, all data for approval and billing is automatically available without any user intervention. * **The Billing Work Order Contains the Master Set:** In the Billing Work Order, new Work Order Lines can be created to connect budget from project planning lines to the Work Order. Sub-Work Orders can only be assigned Work Order Lines from the Billing Work Order. A new budget/project planning line must always be created in the Billing Work Order before it can be assigned in a Sub-Work Order. * **Project of the Work Order:** The project of the Work Order Line does not have to be the same as that of the Work Order. If, for example, the wrong project was initially selected and lines and Time Recordings already exist, the project must be changed, the Time Recordings moved, and new Work Order Lines created. Before the Time Recordings are moved and the old lines deleted, they have a different project than the Work Order (*applies to both Budget Types*). * **Billing Types:** The billing types *Time & Material, Budget, and Fixed Price* are taken from the Budget project planning line. * **Activity:** The activity can be entered in the Work Order Line but serves only as a default value for Time Recordings. The user is always free to change the activity in the Time Recording. #### 4.2. Time Recordings with Work Order Lines It is not possible to select Work Order Lines in the entry mask of Time Recordings. The assignment works via the selection of the Work Order No. and project planning line No. (e.g., via the activity). If there is only one Work Order Line with billing type *Time & Material, Budget, or Fixed Price*, the Time Recording is automatically completed when the Work Order is entered. The Budget Type in the Work Order defines some rules for the Time Recording. * **Budget Type Project:** Work Orders with the Budget Type *Project* restrict the selection in the Time Recording. * If the Work Order has a customer and project, these are automatically completed in the Time Recording. * If there is only one Work Order Line, the project task and planning line with billing type *Time & Material, Budget, or Fixed Price* is automatically completed in the Time Recording. * Work Orders with the Budget Type *Project* do not allow project tasks and planning lines to be selected in Time Recordings for which no Work Order Line exists. * If the Work Order is not the Billing Work Order (has another Work Order entered in Billing Work Order) and **has no own Work Order Line**, all Work Order Lines of the Billing Work Order can be used in Time Recordings. For example, the Work Order Line for a Workshops task is created in the task. No lines need to be created in the Sub-Work Orders that plan the individual workshops. * If the Work Order is not the Billing Work Order and has **at least one** own Work Order Line, Time Recordings for this Work Order can only use these Work Order Lines. By the act of assignment, the selection in the Time Recording is restricted. This minimizes the administrative effort for assigning Work Order Lines to Sub-Work Orders. It is only necessary when the selection is to be explicitly restricted. For a software change with Sub-Work Orders "Development", "Code Review", and "Consulting Test" with 2 Work Order Lines (*Development and Consulting*), the selection for the time recorder can be meaningfully restricted by assigning Work Order Lines to the Sub-Work Order. * **Budget Type Open:** The Open Budget Type gives the time recorder significantly more freedom. The UI and lookups guide the time recorder, but they can override the suggestions at any time. * The first Time Recording with a customer and project fills these in the Work Order. * If the Work Order has a customer and project, these are automatically completed in the Time Recording. * If there is only one Work Order Line, the project task and planning line is automatically completed in the Time Recording. * Time Recordings for Work Orders with Budget Type Open are not restricted to the project tasks and planning lines from the Work Order Lines. The user can select other project tasks and planning lines. The project tasks and planning lines for which Work Order Lines exist are highlighted. * If a new project planning line is selected in the Time Recording, a Work Order Line is automatically created for it. * The Open Budget Type also allows the user to select a different customer and project. The Work Order No. lookup in the Time Recording only shows Work Orders with the same project, but the field does not prevent the entry of a different Work Order. Additionally, the customer and project can be changed after the Work Order is entered. :::info Surcharges Surcharges follow the same logic. They create Work Order Lines for Work Orders with Budget Type Open, and Budget Type Project restricts the selection to the project planning lines for which a Work Order Line exists. A notable difference is that the surcharge is not automatically entered in the Time Recording when there is only one Work Order Line. The time recorder has not automatically traveled just because there is a corresponding Work Order Line. ::: #### 4.3. Reserving and Key Figures Work Order Lines are essentially only connections to a Budget project planning line. The quantity in the project planning line can be distributed between Work Orders. With reservation, Work Order Lines have exclusive access to the reserved quantity, and the reserved quantity is used for the calculation of key figures and the approval of Time Recordings. * **Reserved Quantity:** Specifies the quantity exclusively reserved for the Work Order. If a quantity is reserved, other Work Order Lines cannot use that part of the budget for invoicing. Except for the billing type *Time & Material*, no more than the reserved quantity can be billed. **Note:** More than the available quantity in the Budget project planning line can be reserved. However, the over-reservation cannot be billed as long as the quantity in the planning line has not been increased. This makes it possible to distribute budget before it has been formally increased in the order and project planning line. The *Reserved Quantity* and quantity for project planning lines/Work Order Lines with billing type *Time & Material* increases automatically when Time Recordings are posted. * **Quantity Available for Reservation:** Specifies the quantity that can still be reserved. The calculation takes into account posted and invoiced quantities and reserved quantities, but not open Time Recordings. ```math Quantity \ Available \ for \ Reservation = Quantity \ of \ Project \ Planning \ Line \ (Budget) ``` ```math - Special \ Work \ Order \ ``` ```math Special \ Work \ Order = \sum\limits_1^n(if \ reserved \ quantity > 0, use \ reserved \ quantity \ ``` ```math , else \ use \ quantity \ to \ invoice + \sum\limits_1^n Quantity \ Project \ Planning \ Lines_i \ (Billable)) ``` * **Unit Code:** Specifies the unit used. * **Remaining Budget:** Specifies the quantity that can still be posted. Quantities reserved in other Work Orders that have not yet been posted can still be posted. It is calculated by subtracting the invoiced and still-to-be-invoiced quantities (incl. project planning lines (billable) and quantities to be invoiced in Work Order Lines and project planning lines) from the quantity of the Budget project planning line. Open Time Recordings are not taken into account in the calculation. ```math Remaining \ Quantity = Quantity \ of \ Project \ Planning \ Line \ (Budget) (Billable) ``` ```math - Quantity \ to \ Invoice \ of \ Project \ Planning \ Line \ (Budget) ``` ```math - \sum\limits_1^n Quantity \ Project \ Planning \ Lines_i \ (Billable) ``` ```math - \sum\limits_1^n Quantity \ to \ Invoice \ of \ Work \ Order \ Line_i ``` * **Quantity Billable Open:** Calculated from the sum of the billable duration of Time Recordings for the Work Order with the Budget project planning line with status Open. * **Original Quantity:** Specifies the initially entered quantity in *Reserved Quantity*. This field is not automatically updated, in order to track which budget was originally reserved in the case of budget increases (e.g., billing Time & Material). Work Order Lines can be used **without** a reservation. If there are multiple Work Order Lines without a reservation, they "share" the quantity from the Budget project planning line. During approval of Time Recordings, first come first served applies, meaning that the first approved Time Recording occupies the budget/quantity definitively. If there is no explicit reason to reserve a quantity for the Work Order, it is simpler and less effort to make no reservation. ### 5. Origin The *Origin* tab records where the Work Order was created. None of the fields are editable. If the Work Order was created in Business Central or DYCE Connect, **DYCE** is automatically entered in **Origin**. If the Work Order was created in Jira or Azure DevOps, *Origin*, *Organization (external)*, and *Project (external)* reflect this. The *Link* points either to the Work Order in the external tool or in DYCE Project & Resource Planning. :::warning Origin DYCE If **DYCE** is entered in *Origin*, all fields can be edited as described above. If DYCE is not entered in Origin, some fields cannot be edited. This prevents the data in the external tool and Business Central from diverging. All content related to billing can always be edited in BC: * Customer * Project * Billing Work Order No. * Work Order Lines * Completed * Locked * Planned * Location Changes to these fields cannot be reliably transferred to the external tool. Please take this into account when importing Work Orders via an API or other means. ::: For Work Orders created from Sales Orders, the Sales Order linkage is stored in **Source Document Type** and **Source Document No.** (and **Source Document Line No.** on Work Order lines). These fields are informational and typically hidden by default. See [Creating Work Orders from Sales Orders](/docs/pb/professional-services/creating-work-orders-from-sales-orders). ## Work Order Events For scheduling work in the form of concrete appointments with date and time, so-called **Events** (appointments) can be created for each Work Order. As soon as an event is created for a resource, the Work Order appears in **[DYCE Time Tracking](/docs/web/tt/welcome.md)** in the list of **[Tasks](/docs/web/tt/time-tracking/tasks.md)** for the planned resource. :::tip **[DYCE Project & Resource Planning](/docs/web/prp/welcome.md)** facilitates the planning of multiple resources on any Work Order in a functional and clear graphical interface, the **Work Order Calendar**. ::: ## Status (external) For services, billing usually depends on the progress of work. The **Status (external)** reflects the current state of the task and is synchronized (e.g., from Jira) to Connect and Business Central. Based on the Work Order Type and its status, the system automatically controls whether new Time Recordings can be created and when a Work Order is flagged as ready for invoicing. If a new status is used in Jira that does not yet exist in Business Central, the system creates it automatically during synchronization. The **Status (external)** can only be changed in Business Central if the origin is DYCE (i.e., the Work Order was not created in an external tool). ## Configuration: Status (external) Actions To automate your workflow, define rules on the **Status (external) Actions** page. This tells Business Central how to react to a specific status from Jira. **Step 1: Accessing the Configuration** There are two ways to reach the setup: * **Via Search:** Search for **Status (external) Actions** using the "magnifying glass" icon (*Alt+Q*). * **Via Type (Work Order):** Go to the **Type (Work Order)** page. You will see a new column called **Status (external) Actions** showing a count (e.g., *0*). Click on the number to open the configuration filtered for that specific type. **Step 2: Creating a New Mapping** Click *New* on the **Status (external) Actions** page to create a rule: * **Status (external):** Select the status name from your external tool (e.g., "Done" or "Resolved"). * **Type (Work Order):** Select the type to which this rule applies (e.g., "Bug"). * **Locked:** Activate this checkbox if you want to prevent users from creating new Time Recordings once this status is reached. * **Completed:** Activate this checkbox if the Work Order should be considered "ready for billing" when it reaches this status. |Status (external)|Type (Work Order)|Locked|Completed| |:---|:---|:---|:---| |Resolved|Bug|Yes|No| |Closed|Bug|Yes|Yes| |Done|User Story|Yes|Yes| |Cancelled|*(Empty)*|Yes|Yes| **Key Rules:** * **Type + Status:** You can define different behaviors for different types (e.g., a "Resolved" bug might lock the creation of new Time Recordings, but not yet be set to Completed for billing, because it still needs to be shipped first). * **Global Rules:** If you leave the **Type** empty, the rule applies to all Work Orders where **Type (Work Order)** is also empty. This means you are not forced to use a type if no external system is used. * **Trigger:** The flags are updated the moment the status changes via synchronization or manual entry. **The "Locked" Flag** When a Work Order is marked as "Locked": * **Guardrail:** Users cannot create new Time Recordings for this Work Order. * **Flexibility:** Existing Time Recordings can still be modified, approved, and posted. This is ideal for phases where the work is finished but the recorded times still need to be cleaned up. **The "Completed" Flag** This flag indicates that the work is finished from a functional perspective. It is a primary filter in Project Billing (Approval) to identify Work Orders ready for final invoicing. :::info Important Notes * **Manual overrides:** Even if the automation sets a flag, you can still uncheck it manually on the Work Order card if you need to allow a late Time Recording. * **Removing flags:** The automation can set a flag and also remove it via a different status (e.g., a "Rework" status should clear the *Locked* and *Completed* flags). * **Deletion:** If you delete a mapping rule, existing Work Orders retain their current flags. However, future status changes to that specific status will no longer trigger automatic updates. ::: **Key Rules:** * **Type + Status:** You can define different behaviors for different types (e.g., a "Resolved" bug might *lock* the creation of new Time Recordings, but not yet be set to *Completed* for billing, because it still needs to be shipped first). * **Global Rules:** If you leave the **Type** empty, the rule applies to all Work Orders where **Type (Work Order)** is also empty. This means you are not forced to use a type if no external system is used. * **Trigger:** The flags are updated the moment the status changes via synchronization or manual entry. **The *Locked* Flag** When a Work Order is marked as *Locked*: * **Guardrail:** Users cannot create new Time Recordings for this Work Order. * **Flexibility:** Existing Time Recordings can still be modified, approved, and posted. This is ideal for phases where the work is finished but the recorded times still need to be cleaned up. **The *Completed* Flag** This flag indicates that the work is finished from a functional perspective. It is a primary filter in Project Billing (Approval) to identify Work Orders ready for final invoicing. :::info Important Notes * **Manual overrides:** Even if the automation sets a flag, you can still uncheck it manually on the Work Order card if you need to allow a late Time Recording. * **Removing flags:** The automation can set a flag and also remove it via a different status (e.g., a "Rework" status should clear the *Locked* and *Completed* flags). * **Deletion:** If you delete a mapping rule, existing Work Orders retain their current flags. However, future status changes to that specific status will no longer trigger automatic updates. ::: --- ## Project billing(Pb) # Project Billing **Project Billing** in DYCE streamlines invoicing for professional services and projects by enabling multi-level control and posting of time recordings across project tasks, with options for bulk or individual approvals and advanced functions like quantity transfers and time splits. After release, time recordings are posted, linked sales orders prepared for invoicing, and invoices generated, with cancellation also supported from the same interface. ## General With **Project Billing**, DYCE provides a tool that supports the user in completing his tasks in the context of invoicing professional services and projects as simply and clearly as possible. Controlling and posting of the Time Recordings to the respective project components are done in a multi-level administration page for any number of (filtered) project tasks. * The recorded times for the individual project tasks can thus be easily controlled and released for posting by the project manager. * This release can be done either per Time Recording or for all Time Recordings in a document at once. Alternatively, several project tasks can be marked and released in one step. * Useful functions such as the transfer of (remaining) quantities to other project tasks or the splitting of recorded times are available. * Next step is posting of Time Recordings. The function takes all released Time Recordings into account. In the process, possible linked Sales Order lines are prepared for invoicing in parallel. * In a further step the **[Posting Documents](/docs/pb/posting-documents.md)** (service invoices) are generated. * The **[cancellation of services](/docs/pb/cancellation.md)** can also be triggered via this page. ### Billing for projects The **Project Billing** page contains the overview of the project tasks to be checked, in addition to the selection option of individual views (with previously saved filter presets). In detail, the page is structured as follows: 1. **Filter area** * Here a **[Project Billing Overview Preset](#project-billing-overview-presets)** can be selected. * The date in **Show Time Recordings up to** can be predefined via the preset (if a **Time Recordings Formula** is stored there - see below). The date can also be adjusted manually. It is used to filter the related project tasks based on the **Service Date** and display them accordingly for posting. * The **Invoice Posting Date** specifies the date used when posting the Time Recordings (in the *Usage* type project ledger entries) and for the respective *Billable* project planning lines. 2. **Actions** * **Post Time Recordings** (*Process*) The action posts all released Time Recordings to the (via the [Project Billing Overview Preset](#project-billing-overview-presets)) displayed project tasks. * **Post Quantity To Invoice** (*Process*) Posts the quantity from **Quantity to Invoice** of the selected project tasks. * **Cancel Service** (*Process*) Invokes the Cancel Services function for the selected project tasks. * **Create Purchase Orders** (*Process*) Action refers to ordering external services and creates Purchase Orders for the selected project tasks. For further explanation, see [this](pb/purchase/purchase-external-resource.md) part of the DYCE documentation. * **Invoicing** (*Process*) The page that opens displays the project planning lines that can be invoiced. This can be used to create [Posting Documents](/docs/pb/posting-documents.md) - even without a Sales Order. * **Quick Filter** (*Process*) For ad hoc filtering of project tasks, this action can be used in addition to [Project Billing Overview Presets](#project-billing-overview-presets). It opens a filter page where the criteria for filtering can be entered. This will take the filter criteria from the currently selected view as default values. * **Release Time Recordings** (*Time Recordings*) Time Recordings for all selected project tasks are released at once. * **Reopen Time Recordings** (*Time Recordings*) This action resets the release of Time Recordings for all selected project tasks. * **Edit Time Recordings** (*Time Recordings*) Opens the page of the same name where *Budget* project planning lines can be viewed and Time Recordings can be edited. * **Project Card** (*Project*) The action opens the project Card of the selected project task. * **Project Sales Invoices** (*Project*) The action opens an overview of unposted Sales Invoices for the selected project. * **Posted Project Sales Invoices** (*Project*) The action opens an overview of posted Sales Invoices to the selected project. * **Project Sales Orders** (*Project*) The action opens an overview of the Sales Orders belonging to the selected project. * **Project Task Card** (*Project Task*) The action opens the card of the currently selected project task. * **Project Planning Lines** (*Project Task*) The action opens the project planning lines of the currently selected project task. * **Sales Order** (*Project Task*) The action opens the Sales Order (if any) belonging to the currently selected project task. 3. **Project Tasks** (lines) * The Project Billing lines show the project tasks for which times have been recorded within the specified filter (see *[Project Billing Overview Presets](#project-billing-overview-presets)*). * In addition to project and customer, the related Sales Order (if any), total Time Recordings and Budget information are also shown. * When switching *[Project Billing Overview Preset](#project-billing-overview-presets)*, the display of project tasks will be updated if necessary. * Clicking on any of the Time Recordings fields (**Time Recordings Not Released**, **Time Recordings Released**, **Billable Time Recordings**, **Not Billable Time Recordings**) opens an [additional page](#edit-and-release-of-time-recordings) for checking, editing and releasing the Time Recordings. * Clicking on one of the budget fields (**Quantity Sold Budget**, **Budget (Total Price)**) opens the corresponding project planning lines (for **Invoiced (Total Price)** the project ledger entries). * As an alternative to the actions and fields, a variety of calls for Time Recordings, projects and project tasks are available via the AssistEdit of the lines. :::info Include all past Time Recordings The date in the header field **Show Time Recordings up to** will take all past Time Recordings into account. This way, no service to be invoiced can be overlooked (as long as the filter criteria from the Project Billing Overview Preset are correct), since all past Time Recordings are automatically part of the filter. ::: :::tip KPI **Remaining Budget** indicates the remaining budget (quantity) for the project task. All project planning lines with a **Service Billing Type** are used for calculation. This KPI should not turn negative. ```math Remaining \ Budget = \sum\limits_1^n Quantity \ Project \ Planning \ Line_i \ (Budget) \ - \sum\limits_1^n Quantity \ Project \ Planning \ Line_i \ (Billable) ``` **Not Billable Time Recordings** indicates the duration of time recordings (display unit from **Project Billing Overview Preset**) that will not be invoiced. In a time recording with a duration of 1 hour and a billable duration of 45 minutes, 15 minutes are not billable. If the KPI is negative, more than the duration will be invoiced after releasing and posting the time recordings. This is usually the case when rounding from the **Time & Travel Model** has been applied. Example: A time recording with a duration of 5 minutes and a billable duration of 15 minutes (e.g., due to rounding from the Time & Travel Model to 15 minutes) results in **Not Billable Time Recordings** of *-10 minutes*. **Not Billable Time Recordings** of 0 means that the entire duration will be invoiced. If the KPI is disproportionately far from 0 and it is not an internal project, the time recordings should be checked more closely. ```math Not \ Billable \ Time Recordings = \sum\limits_1^n Duration \ Time \ Recordings_i \ - \sum\limits_1^n Billable \ Duration \ Time \ Recordings_i ``` The time recordings are filtered by **Status** *Open* and *Approved*. ::: ### Project Billing Overview Presets Any number of views (as filter presets) can be created for filtering the services (project tasks) to be invoiced. Clicking on the AssistEdit in the **Project Billing Overview Preset** field will open the related page. In addition to a unique code and description, each view requires the specification of filter criteria and defaults for date calculation. The defaults for date calculation are specified in the form of a dateformula. For more information on using dateformulas, please see this part of the Microsoft documentation. The actual date values are then calculated based on the workdate when a view is selected. This allows the defaults to be used continuously without having to be adjusted. When a view is selected, the filters are applied as to which project tasks should be displayed in **Project Billing** page. All fields from the project tasks are available as filter criteria. To define the filters, the **Edit Project Task Filter** action is called. A *filter page* opens where the criteria can be defined. In addition to the pre-set criteria, further criteria can be added (via *+ Filter...*). If the *filter page* is closed via *OK*, the criteria are saved in the view. This can be recognized by the fact that a check mark is set in the **Project Task Filter** field. If only those projects are to be displayed in which the user himself is stored as ***Project Manager***, the indicator can be set for this in the **My Projects** field. In the **Time Recordings Formula** field, a dateformula is entered that will be interpreted when using the view in the **Show Time Recordings up to** field. This field is then used to filter the project tasks to be billed (based on the **Service Date** in the Time Recordings). If no dateformula is specified, **Project Billing** will not use a filter. The **Display Unit** field is used to specify the unit in which Time Recordings are displayed. The choices here are *Day* and *Hour*. In addition, the **Copy Preset** action provides the option of creating a copy of the currently selected view including all filters. Thus not all criteria must be entered again, but only the deviating criteria must be changed. :::tip Note If you only want to view a specific project or invoice per project, filter on the **Project No.** - either via a **Project Billing Overview Preset** or via the **[Quick Filter](#billing-for-projects)**. On the other hand, if a project manager wants to check all of his projects at once, filtering on the **Project Manager** makes sense. ::: #### Special filter criteria **Time Recordings to Release** and **Time Recordings to Post** The two filter criteria are related to Time Recordings that belong to the specific project task. **Time Recordings to Release** tends to be more applicable to the project manager, **Time Recordings to Post** tends to be more applicable to the person posting the Time Recordings. Three options can be selected for each of the two criteria: |Option|Meaning| |:--|:--| |*EMPTY*|This option displays all data.| |Yes|This option is used to display project tasks in which Time Recordings are either *to be released* or *to be posted*. |No|This option is used to display all project tasks that do not contain *releasable* or *to be posted* Time Recordings. :::info Using special filter criteria Especially the filter criterion **Time Recordings to Release** should be carefully considered. Depending on what is to be displayed, it may make sense to leave the filter set to *Empty* for the time being. If the filter is set to *NO*, all project tasks that contain Time Recordings that have not yet been released for posting will be displayed. However, at the moment of releasing, these are immediately filtered out and thus disappear from the list. This behavior is useful, for example, when you want to work through the release of Time Recordings and the progress should be visible. ::: ### Edit and release of Time Recordings Time Recordings can generally be released without a detailed check. To do this, select the project tasks and call up the **Release Time Recordings** action (via *Time Recordings*, see above). This way of working can be useful in individual cases, but is generally not recommended. On the other hand, the detailed check and subsequent release of Time Recordings is done either by clicking on the value e.g. in the **Time Recordings Not Released** field or via the **Edit Time Recordings** action (via *Time Recordings*, see above). It opens the page of the same name, where the *Budget* project planning lines are displayed and the Time Recordings can be edited and then released. Separate areas display the services (*Budget* project planning lines) at the top and the Time Recordings of the employees at the bottom. The following actions are available in this page: * **Increase quantity** This action increases the quantity of the project planning lines using a query. This shows the current quantity and, if applicable, the Sales Order. If the project planning lines is linked to a Sales Order line, the change also affects the Sales Order line. * **Toggle Time Recordings** This action toggles the status for all *selected* Time Recordings. In each case, the other value (Open / Released) is set. * **Release All Time Recordings** The action releases all Time Recordings for posting. * **Reopen Time Recordings** The action resets the release for all Time Recordings. * **Post Quantity To Invoice** The action posts the value in the **Quantity to Invoice** field of the currently selected project planning Line. Time Recordings are related to a service (see top of the page) and are therefore generally billable. However, they can also contain non-billable parts such as *Goodwill*, *Warranty*, *Internal* or *Customer Contract* times. By assigning them to services, the Time Recordings will be **bold** formatted based on the highlighted service in each case. As long as a Time Recording is not yet posted, all fields can be changed. In addition, a Time Recording can be split differently in terms of total duration or moved to another project task (or even to another project - see below). If a part of a Time Recording should not be invoiced, the time can be reduced accordingly in the **Billable Duration** (or **Billable Duration (Hours)**) field. Initially, these fields are predefined by the **Duration** (and **Duration (Hours)**). In case of a reduction, a reason for the non-billing (field **Non-billable Reason**) must be specified at the same time. Here, the selection is initially predefined as *Internal* or based on the Time & Travel Model line. However, this can be changed. Via the line menu, the **Move Time Recordings** function provides the option of moving a time recording that has not yet been posted from one project task to another project task or even to another project - the action is available the same way from both **Project Billing** and **Project Billing (Approval)**. When the action is called, a selection page opens, in which the data of the Time Recordings are already given as a starting point. An editable **Sell-to Customer No.** field (with a read-only **Sell-to Customer Name** shown alongside it) makes it easy to move to a project of a different customer: changing the customer clears the project selection (or fills it automatically if the customer has only one project), and changing the project updates the customer. For moving the project, the project task and the project planning line budget can be selected. By clicking OK, the Time Recording will be moved accordingly. If the project task has no Work Order Line yet for the selected Work Order, a **Create Work Order Line** toggle lets the project task and project planning line budget be selected directly, as if there were no Work Order. Confirming the move then creates the missing Work Order Line automatically. Alternatively, the **Add Lines from Planning Lines** action on the **Work Order Lines** lookup opened from the project task field creates (and selects) a Work Order Line for an open project planning line budget with a Service Billing Type, the same way it works from the [Work Order](/docs/pb/professional-services/work-order.md) card itself. An Additional Service on the moved Time Recording still gets its own Work Order Line created automatically either way. For further explanation on Time Recording and non-billable portions, please refer to [this](/docs/pb/time-recording.md) part of the DYCE documentation. ### Proof of activity via Timesheets Before receiving a Service invoice, some customers require advance proof of which services will be invoiced soon. For this purpose, the **Create Timesheet Report** action (menu group *Time Recordings*) is available in the **Project Billing** page. It allows for each project task to create a summary of Time Recordings in the form of a receipt that can be printed or emailed to the customer. When called, the **DYCE Timesheet** page opens, displaying the Time Recordings for the previously selected project task, which are within the date filter. Time Recordings cannot be edited in this page. For each Time Recordings, it will show whether it was already included in a prior Timesheet report (**Printed**=*YES*). The **Print** field is used to indicate which Time Recordings should be printed (or emailed). Time Recordings that have already been printed can be printed again. To select all Time Recordings at once, the **Toggle Print** action is useful. The **Print** action opens a dialog that controls the output of the previously selected Time Recordings. ## Process: Review, release, and post Time Recordings The following part of the documentation will introduce the process of billing services using **Project Billing** by an example of a particular project task. ### Manage Time Recordings In practice, the review and, if necessary, adjustment of the Time Recordings made by the employees, as well as the subsequent release of these *project consumptions* for billing, is usually carried out by the respective project or team leaders, since they are better able to evaluate the content of the activities carried out than, for example, a Sales Order Processor. To ensure that only the employees' time recordings that have not yet been posted are displayed in the first step, it is advisable to create a suitable view for checking and approving the project tasks. Suggestion for defining the filters for the view for checking and releasing the consumptions: * My Projects = Yes * Time Recordings Formula = -CM-1D (here: to the last day of the previous month) * Time Recordings to Release = Yes (*Filter page Project Tasks*) **Time Recordings to Release**=*Yes* searches for all project tasks for which there is at least one time recording with **Status**=*Open*. All time recordings with the **Status**=*Open* or *Released* are displayed in the project task to make it easier for project managers to find time recordings that have already been approved but not yet posted. The filters **Time Recordings to Release** and **Time Recordings to Post** should not be used in combination. ### Increase or decrease the recorded quantities The total of assigned Time Recordings for a billable service (*Budget* project planning Line) is displayed in the **Billable Time Recording Released** or **Billable Time Recording Posted** fields. If the Time Recordings exceed the original calculated billable quantity, a decision must be made as to the correct procedure for this project task: * For a project planning Line with Service Billing Type *Time & Material*, it is assumed that the (billable) quantity may be increased by expense without any problems. This is done automatically and may be carried through to the Sales Order line. In this case, no user intervention is required, because when the Time Recordings are posted, the quantity in the project planning Line is automatically increased to match the associated Time Recordings. * If, on the other hand, the project planning Line is of one of the Service Billing Types *Budget* or *Fixed Price*, this rule does not apply. In these cases, the service has been sold as a flat rate or Fixed Price and cannot be increased at will. For better visibility, the project task that contains such an *overbooked* project planning Line will be displayed in red format in the **Project Billing** page. The project manager (or other responsible person) must now decide how to handle the overbooking of the service: Can and may the quantity in the project planning Line be increased? This question arises especially if the project planning Line is linked to a Sales Order: * If the Sales Order Line still offers an available quantity, a manual increase of the quantity in the project planning Line to the assigned quantity would be possible in principle. * However, if the quantity in the Sales Order for this line is already exhausted, the quantity in the project planning Line cannot be increased. In this case, the only option (after consulting with the customer) is to increase the quantity in the Sales Order line. However, this must be done manually. The action **[Increase quantity](#edit-and-release-of-time-recordings)** can be used to increase the quantity including the adjustment of the Sales Order line, e.g. after consultation with the customer. If a quantity increase in the (flat-rate) project task line is excluded for contractual reasons, there is still the possibility of transferring the Time Recordings that have not yet been booked to another project task (or also to another project) with quantities that are still free. The corresponding function **Move Time Recordings** (see [Edit and release of Time Recordings](#edit-and-release-of-time-recordings)) is located in the line menu of the bottom section of the **Edit Time Recordings** page. :::tip Special feature: Billing of Fixed Price services In order to invoice Services at Fixed Price, they must be somehow marked as *completed*. This is done by entering the (total) quantity to be posted in the **Quantity to Invoice** field in the Budget project planning Line. This step cannot be done automatically, as only the project manager (in coordination with the Time Recorder, if applicable) can assess whether the related activities have been completed and the corresponding Sales Order line can therefore be invoiced. If the total quantity of a Fixed Price item is reached with the posting (delivery), the **Qty. to Invoice** field in the Sales Order line is automatically predefined with this quantity. ::: ### Releasing consumptions To release the Time Recordings, the project manager filters (via an appropriate [View](#project-billing-overview-presets)) on the projects or project tasks for which he is responsible, for example. If in this view the filter for checking Time Recordings is set to *YES* and the filter for releasing project tasks is set to *NO*, all project tasks that have not yet been released for posting will be displayed. Immediately after checking and setting the release in all Time Recordings, the project task disappears from the current view due to the set filter and the project manager can continue with the next project task in the list. Releasing can be done per Time Recording (**Edit Time Recordings** page) or by using the **Release Time Recordings** action in the menu bar of the **Project Billing** page for all selected project tasks at once. In the latter case, the **Status** field is automatically set to *Released* for all Time Recordings that have not yet been posted. In doing so, the **Quantity to Invoice** field in the related *Budget* project planning Line is updated for each release. ### Post released Time Recordings If the time recordings have been checked by the project manager and the posting release (**Status** field = *Released*) has been set, the posting of the consumptions (or Time Recordings) can also be done by a Sales Order Processor using batch processing. For this, the person also uses the **Project Billing** page - but with a different view: * My Projects = No * Time Recordings Formula = -CM-1D (here: to the last day of the previous month) * Time Recordings to Post = Yes (*Filter page Project Task*) Posting of released Time Recordings is done via the **Post Time Recordings** action (via *Process*). When posting, the **Billable Time Recording Released** and **Billable Time Recording Posted** fields are updated in the respective related *Budget* project planning lines. If applicable, the amount of the *Budget* project planning Line is also increased for *Budget* project planning lines with Service Billing Type *Time & Material*. If there is also a link to a Sales Order and the total quantity there is also exhausted, the quantity will also be increased accordingly. Time Recordings to Post = Yes searches for all project tasks for which there is at least one time recording with the status **Released**. All time recordings with the status Open or Released are displayed in the project task. Time Recordings to Release and Time Recordings to Post should not be used in combination. **Set quantity to be invoiced manually** If less quantity has been allocated to consumption than originally planned, the **Quantity to Invoice** in the project planning Line can be set to the quantity to be billed for services with one of the billing types *Budget* (if required) and *Fixed Price*. Afterwards, the action **Post Quantity to Invoice** must be called. If this less consumption should actually be billed less (e.g. final billing), the **Quantity to Invoice** in the project planning Line (for the two billing types *Budget* and *Fixed Price*) can be reduced to the actually assigned quantity of Time Recordings. :::info Post in Job Queue All released time recordings can be posted in the job queue using Report 70920909 "Post Time Recordings". If a time recording cannot be posted (e.g., due to an existing credit memo), it will be skipped. ::: ### Create Posting Documents After the Time Recordings have been posted, the services still need to be invoiced. This can be done either directly via the respective Sales Order or via Posting Documents (Invoices and Credit Memos). The Sales Orders that contain billable services are displayed in the **Project Orders - Service Billing** page. Here, using the *Post* menu item, invoices can either be created in batches and posted directly (**Batch Post** action) or individual unposted invoices can be created (**Create Sales Invoices** action). The page can be opened via the search (*Alt+Q*). Alternatively, the **Invoicing** call is available in **Project Billing** page. This opens the **Project Invoicing** page, which displays all the project planning lines that can be invoiced. Here, too, there is the option of creating the posting documents by batch processing and posting them directly, if necessary. Further details on posting documents are explained in more detail [here](/docs/pb/posting-documents.md). --- ## Purchasing external resources # Handling and purchasing of external resources **DYCE Project Billing** provides the option, in conjunction with Projects and services, to have these services performed by people outside of your own organization. The purchase of these external resources is handled via a Blanket Purchase Order together with resources set up properly. If necessary, Project-specific conditions can be stored in the Blanket Purchase Order. The following section outlines an example process flow. ## Basic process 1. The resource of the external employee is linked to the corresponding vendor. For this purpose, the **Vendor No.** is entered in the resource card. 2. A Blanket Purchase Order is created for the vendor that was linked to the resource in the previous step, whereby the resource, the expected order quantity, the purchase price and the Project (**Project Reference**) are entered in the line. The Blanket Purchase Order can be sent to the vendor (or the external employee / freelancer) if required. 3. Either the external employee records his times for himself (e.g. in ***DYCE Time Tracking***) or he sends proof of service at the end of the month. In the latter case, the Project No., Project Task, quantity, date and Blanket Purchase Order No. must be included here. Based on the proof of service, the Project Office creates corresponding Time Recordings (on behalf of the external employee). 4. When entering the Time Recordings, the system checks if there is already a Blanket Purchase Order Line No. for the combination of *Resource* and *Project* and suggests it. 5. When the Project Manager checks and releases the Time Recordings, the system automatically checks to see if a Blanket Purchase Order No. is entered on all lines. If not, a number can be entered. 6. Time Recordings are posted and Project Ledger Entries are created (type *Usage*). At the same time, a check is made to see if there is a corresponding line in a Blanket Purchase Order for the external resource. The reference to this purchase order line is created in the Project Ledger Entries. 7. A Purchase Order for the Blanket Purchase Order is generated using the **Create Purchase Orders** function (via *Process* in the **Project Billing** page, among others). In this process, the Time Recordings of the external resource are summarized based on the Project. In the Time Recordings, the purchase order number and the purchase order line number are stored. 8. The Time Recordings of the internal and external employees are charged to the customer. When the *Sale* Project Ledger Entry is generated, it is marked (via the link to *Usage* Project Ledger Entry) as *Accrual Required*. However, only if the related purchase order line has not yet been invoiced at that time. 9. Accruals must be created for Customer revenues from external employees for which costs have not yet been posted. To do this, a job runs through all purchase order lines and checks the associated Project Ledger Entries to see whether accruals are necessary for this. For these Project Ledger Entries, a line is created and posted in the accounting ledger sheet. With the posting, the indicator in the Project Ledger Entries is reset. 10. When the incoming invoice from the vendor arrives, it is checked and posted. If there is a posted accrual at this time, then it is released with a corresponding offsetting entry. If there is no accrual at this time, then no change is necessary. The actual purchase price is updated in the *Usage* Project Ledger Entries. :::note Purchase Price from Blanket Purchase Order The purchase price used in the purchase order is the same as the purchase price from the Blanket Purchase Order. When time recordings are posted for external resources, the unit costs for the *Usage* Project Ledger Entries are transferred from the purchase price of the Blanket Purchase Order line in each case. ::: ## Notes on Purchase Orders and Accruals In the Role Center **Project Administrator** there are two tiles **Purchase Orders required** and **Accrual required** under the heading **Purchase Orders**. If a Time Recording is posted for an external resource (for which a corresponding Blanket Purchase Order has been found) for which *no* Purchase Order exists yet, this will be displayed in the **Purchase Orders required** tile. Clicking on the tile opens the overview of the records in the page of the same name. The purchase orders can be created via the **Create Purchase Orders** action (*Process* action group) and then posted (see point 6 in the [previous section](#basic-process)). Alternatively, purchase orders can be created using the action of the same name in **[Project Billing](/docs/pb/project-billing.md)**. If a Service provided by an external employee has already been invoiced to the customer before the vendor's invoice has been received, this will be indicated in the **Accrual required** tile. Clicking on the tile opens the overview of the records in the page with the same name. The accruals can be created first as lines in a accounting ledger sheet via the **Start Accrual Posting Project** action (*Process* action group) and then posted (see point 8 in the [previous section](#basic-process)). :::warning Attention To create an accrual, the purchase order must already have been created. However, the purchase order does not have to be posted in order to create the accrual. ::: --- ## Working With Purchase Documents # Working with purchase documents The [Purchasing](https://learn.microsoft.com/en-us/dynamics365/business-central/purchasing-manage-purchasing) of items for Projects is basically no different from that in Business Central. However, items are usually ordered on an Sales Order or Project basis. For this purpose, the separately available app **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** offers a simplification compared to the standard of Business Central. Further explanations on how to create project-related Purchase Orders can be found in [this](/docs/ibt/sales-related-procurement.md) part of the DYCE documentation. :::info In **[Role Center](/docs/pb/first-steps.md)** *Project Administrator* there are two tiles **Purchase Orders required** and **Accrual required** under the heading **Purchase Orders**. These indicate whether purchase orders (based on time recordings) or accruals (based on an outstanding purchase invoice) still need to be created for external resources. For more details on purchasing external resources, see [this](/docs/pb/purchase/purchase-external-resource.md) part of the DYCE documentation. ::: --- ## Purpose(Pb) # Purpose and benefit of DYCE Project Billing The aim of project invoicing with **DYCE Project Billing** is to be able to invoice services and items (later also travel expenses) for a customer project in one step via Sales Orders and to control the project's budget. All commercial aspects of a project can be recorded and calculated in quotes and orders. A project manager can check Time Recordings and release them for invoicing. At the same time, the project manager receives an overview of the current status of the project's budget. Project requirements such as hardware or external services can be ordered on an order-by-order basis. The services to be provided in the project can vary and therefore they can be billed according to Time & Material, as a lump sum or at a fixed price. The details of the billed services are listed in a Detail Overview per invoice. Cancellation of services including automatic correction of the project budget is also possible. In order to make time recording as easy as possible for the user, a time recording model is available for each project. The time recording model also supports rounding to whole work units for billing to customers. Users can do time recording in ***[DYCE Time Tracking](/docs/web/tt/welcome.md)***. There is integration in the form of add-ins in Azure DevOps and the Jira products from Atlassian. A version for mobile devices will follow later. --- ## Handling Project Tasks # Handling Project Task and Planning Lines The **Manage Project Tasks** action in the sales order card simplifies the creation, management, and budgeting of Project Tasks (PT) and Project Planning Lines (PPL), which are essential for the creation, releasing, posting and invoicing of time recordings. The page allows users to easily divide the budget from a single sales line into multiple, fine-grained budget, structured Project Tasks and to provide better visibility into budget allocation. :::info Additional Info Background on *Project Tasks* and *Project Planning Lines* is explained in [this section](/docs/pb/masterdata/project-task-planning-line.md) of the DYCE documentation. These elements form the basis for creating [Time Recordings](/docs/pb/time-recording.md) and billing [Services Items](/docs/pb/masterdata/item.md) within a project. ::: The following section describes how Project Tasks and Project Planning Lines can be created and edited directly from sales orders. ## Manage Project Tasks The **Manage Project Tasks** page provides a centralized, structured view of your budget allocation. It is opened in the sales order card via the action with the same name. To open the page, the sales order must already be linked to a **Project**. When opened for the first time it displays all sales lines with a [Service Billing Type](/docs/pb/masterdata/item.md#differences-in-service-billing-items). When Project Tasks and Planning lines have been created, they are presented in a tree view. **Page Structure (Tree View)** * **Top-level (parent):** Sales lines (only those for professional services) - represent the total available budget. * **Child elements:** The corresponding Project Planning Lines (PPL) Budget that have been or will be created under that sales line. Each PPL links to a separate Project Task. The individual lines are labeled by the **Line Type** (*Sales Line* or *Project Planning Line*). It cannot be edited. Description, Quantity, Quantity (Initial) and Status can be edited. ### Key Actions |Action|Description|Best Practice Advice| |:---|:---|:---| |New|Creates a single Project Task (and PPL) for the selected sales line. It assigns the entire available quantity to the new line.|Use for simple, single-task projects or when a quick setup is needed before detailed planning. If multiple Project Task (and PPL) are needed, click the action multiple time and change quantity as well as description in the created lines.| |Create All|Creates one Project Task (and PPL) for each Sales Lines displayed, assigning the available quantity.|Use to create a default PPL for every sales line with a single click.| |Delete Planning Line|Deletes the selected PPL(s) and their associated Project Task(s).|Use to remove budget allocations before time is recorded against them.| ### Important Indicator Fields and Calculations |Field|Description|Calculation| |:--|:--|:--| |Quantity|Specifies the quantity of the sales line and project planning lines.|| |Quantity (Initial)|The quantity initially set on the sales line or PPL budget line.|Set when a quantity unequal to 0 is first entered. **It is NOT updated later.**| |Available to Assign|The remaining quantity on the sales line budget that has not yet been allocated to PPLs.|Sales Line Quantity *minus* Sum of all connected PPL Quantities| |Remaining Budget|The quantity of PPL that is actually still freely available for time recordings. Once time recordings have been created, posted, or invoiced, the entire quantity is no longer available.|PPL Budget Quantity *minus* Qty. of Associated PPL Billable *minus* Qty. to Invoice of PPL (Budget) *minus* Billable Duration of Open Time Recordings| --- ## Project Tasks and Project Planning Lines Background on Project Tasks and Project Planning Lines are explained in [this](/docs/pb/masterdata/project-task-planning-line.md) part of the DYCE documentation. They form the basis for Time Recordings and billing of services. The following part specifically discusses the creation of Project Tasks and Project Planning Lines from Sales Orders. ## Create Project Tasks from the Sales Order The **Create Project Tasks** page displays the Sales Order lines with *[Service Billing Items](/docs/pb/masterdata/item.md#differences-in-service-billing-items)*. A prerequisite for calling the action is that the Sales Order has a link to a Project. In detail, the page displays the quantity and prices of the Service Billing Items of the Sales Order. The **Quantity for Project Budget** field is used to specify the quantity that will be transferred to the Project Task (and Project Planning Line) to be created. The system always suggests the current remaining quantity. However, this can also be reduced. The **Project Task** field has two functions: * On the one hand, the description for Project Tasks to be created (proposal based on the description of the Sales Order line) is defined here. This can also be changed. * On the other hand, the field has an AssistEdit, which can be used to select an existing Project Task created from the same Sales Order. In this case, another Project Planning Line with the specified budget will be created for the selected Project Task. This way, (partial) budgets of several Sales Lines can be combined into individual Project Tasks. The **Create other Project Tasks** action (via *Process*) creates Project Tasks for all lines in the Sales Order that *do not* contain services. This step is optional, as the system will otherwise create these Project Tasks automatically when the items are shipped. However, you may want to create these Project Tasks using the function to get an overall view of all parts of the Project and their progress via the lines in the Project Card (*Project Tasks*). Further explanations of Project Tasks and Project Planning Lines can be found in [this](/docs/pb/masterdata/project-task-planning-line.md) part of the DYCE documentation. :::info Numbering scheme for Project Tasks Project Tasks that are created using one of the above functions follow this principle: * For each Project Task, a *Begin-Total* line is first created to indicate the beginning of the summary. * The number is made up of **two parts**. The first part is **three digits** and describes the **block**. It begins with **001** and is incremented by **1** per Project Task on the Project. * The second part is **four digits** and continuous per line within a block. It starts with **1000** per block and increases by **10** per line. * This is repeated for all Project Tasks to be created - whether for services or miscellaneous. * Lastly, a *End-Total* line is created to indicate the end of the summary. The *End-Total* line displays the cumulative values of the lower-level (indented) Project Tasks. ::: ### Project Planning Lines According to the settings in the **Create Project Tasks** page, the Project Tasks are created. A Project Planning Line with the **Line Type** = *Budget* is created for each Project Task. This will later be used as a reference point during time recording. The **Document No.** contains the number of the Sales Order for which the Project Task and the Project Planning Line were created, the Service Billing Item (**Type** and **No.**) and the corresponding **Billing Type**. The **Description**, the **Unit of Measure Code**, the **Quantity** and the **prices** are taken from the Sales Order line. When Time Recordings are posted, another Project Planning Line - with **Line Type** *Billable* - is created based on the *Budget* Project Planning Lines. The quantity for this Project Planning Line is equal to the total quantity of related Time Recordings. When invoicing the Sales Order, not only the order line is posted, but also the related *Billable* Project Planning Line. At the same time (when the invoice is posted), corresponding Project Ledger Entries are created in the background. In addition, the **Invoicing Document Type**, **Invoicing Line No.** and **Invoicing Line No.** fields create a unique link between the *Billable* Project Planning Line and the invoice line. A *Billable* Project Planning Line can only be linked to one particular invoice line. --- ## Working With Projects # Working with Projects ## Integration of Projects into the sales process In the standard version of Business Central, there is almost no connection between the sales module and the project module. This means that an integrated process, where the Sales Order includes the total budget, which is invoiced based on the progress of the project, cannot be mapped. So there is no possibility to invoice a offered Project (or the respective project components) to the customer based on Time Recordings. Project Tasks and Project Planning Lines are required for the provision and billing of services (in the form of Time Recordings). In the standard of Business Central, however, these are only created when an item is shipped, for example. Since services are represented in the form of items, this point in time is too late from the point of view of the time recorder. Therefore, **DYCE Project Billing** was used to integrate the Project into the sales module and to create the Project Tasks required for time recording on the basis of the Sales Order. At the same time, the project managers' requirement that the individual partial budgets (in the form of Sales Order items) can be broken down into even smaller components was encountered by this implementation. ### Illustration using the example of a software implementation project A software implementation project consists of the sale of the corresponding licenses, consulting services in the form of workshops, training sessions and project management accompanying the project, and development tasks for adapting or expanding the software's range of functions. It takes about half a year and is divided into several phases. The consulting budget is to be divided into the number of workshop and training sessions and the development budget is to be divided into the individual adjustments, so that a budget overrun in a sub-area can be identified immediately. The total budget splits up into licenses, consulting and development services with the corresponding quantity. For the particular activities (e.g. workshops and training or also the changes to be implemented) the project manager needs in each case individual Project Tasks with the appropriate partial budget. Here the system is to support him. At the start of the project, a training session is held for the key users before entering the workshops. The consultants involved record their times on the designated Project Tasks (more precisely: the related Project Planning Lines). At the end of the first month of the project, the services performed within this month are to be invoiced. For this purpose, the project manager can use a filtered view (in **[Project Billing](/docs/pb/project-billing.md)** page), which displays the Project Tasks of *his* projects for which time has been recorded. After review, he releases the Time Recordings for posting. The project office posts these Time Recordings, creates the invoices in the next step and posts them, as well. The posted invoices are sent to the customers including a Detail Overview, which lists the details of the services provided. --- ## Sales-related Procurement(3) # Procurement in connection with a Sales Order In Business Central, there are several ways to create Purchase Orders for retail items. The most common are the Requisition Worksheets (from the manufactoring module) and the functionality to create Purchase Order from a Sales Order. However, if retail items are needed explicitly for a specific Sales Order, these two options fall short. In both cases, the goods are not ordered on an order-by-order basis. Thus, the reservation of the required quantity in the Sales Order line must be done manually. Especially in the second case, both the order (here: Sales Order line) lacks the link to the Purchase Order (here: Purchase Order line) expected by the user and vice versa. ## Create Purchase Order For this requirement, the separately available app **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** offers a simplification compared to the standard of Business Central. Further explanations on how to create Sales Order-related Purchase orders can be found in [this](/docs/ibt/sales-related-procurement.md) part of the DYCE documentation. ### Project prices for purchasing with special bid Suppliers sometimes grant discounts on individual orders, projects or customers-related purchase orders. For this, the quantity and price (and discount, if applicable) are specially negotiated. Orders for which such a project price has been negotiated must be processed separately. It is in the nature of things that there is always a Sales Order for this type of Purchase Order. A reference number (*Special Bid*) is assigned by the supplier for the project price. As a rule, this kind of special order is only processed by the supplier if the reference number is given in the order. If the reference is not included, the discount will not be granted or the order will not be processed. To create and process such orders, a reference number can be entered in the Sales Order line (in the **Special Bid** field). Provided that the app **[DYCE IT-Business Toolkit](/docs/ibt/welcome.md)** is installed, the reference will be added to the Purchase Order via the **Create Connected Purchase Orders** functionality (see above and in the [Create Purchase Order](/docs/ibt/sales-related-procurement.md) section) and can thus be printed. This also applies to Purchase Orders created via the Requisition Worksheet. When creating Purchase Orders, they are always unique with regards to Special Bid. Different order lines with the same reference number can be combined into one Purchase Order. :::info Reservation If an Sales Order line contains a reference number, the reservation is never made against any available stock. ::: --- ## Working With Sales Documents # Working with Sales documents ## Business process A Sales Order is created and linked to a Project. The project's components are entered as Sales Order items. Based on these, the next step is to create the particular components or work packages for the services in the form of Project Tasks. These will be needed later for time recording. Since large budgets can be distributed among several subtasks in this step, this activity is usually one of the tasks of the project manager. This can also be done in several phases at different times. In addition, other Project Tasks (e.g. for trading goods) can be created. However, this step is optional, as the system also automatically creates these Project Tasks when the items are shipped. The employees record their times per respective task during the project's runtime. There are several options available for this. The recommended way is via ***DYCE Time Tracking***. It is irrelevant whether the services are provided by internal or [external employees](/docs/pb/purchase/purchase-external-resource.md). Using **[Project Billing](/docs/pb/project-billing.md)**, the project manager checks the Time Recordings, makes any adjustments regarding chargebility or description, and then releases them for posting. In the system, the posting of the Time Recordings (and thus confirmation that the service has been provided) corresponds to the *shipment* of the corresponding service. In the Sales Order for the Project, the related lines with the corresponding quantities are marked as *shipped*. In the next step, these services can be invoiced. During this process, the invoice can be automatically supplemented with details in the form of a Detail Overview, on which the billing is based. Whether the Detail Overview should be created can be defined in the Project Card. When printing invoices, this setting can be overridden via the **Print Service Details automatically** field. If the invoices are printed in a batch, the setting will be taken from the respective Project. To evaluate the contribution to the Project's revenue, the *[invoiced shares](/docs/pb/controlling.md#determine-proportional-invoiced-shares)* are determined per employee. The integration of the Project into the sales process is illustrated in [this](/docs/pb/sales/projects-in-sales.md) part of the DYCE documentation using the example of a software implementation project. ### Characteristics of a service project * The Sales Order contains a detailed listing of the services sold. * The Sales Order is linked to a Project in the document header. * Times are recorded for the services to be billed. * Each Time Recording can be directly assigned to a Sales Order line or Sales Invoice line. * It is possible to create Project Tasks without a related Sales Order. * Invoicing is done through the Sales Order or through a batch function. * Using the Project, all data is summarized based on one dimension. ## Creating a Project For the sake of simplicity, it is recommended to create a new Project directly from the contacts or the customers overview (via *New document / Project*). Via the fact box **Sales History** you can see which projects already exist for the customer. Alternatively, a new project can also be created directly via the sales document (field **Project No.** + *New*). If Project-specific prices have been agreed with the customer, these are stored via the Project in the **Prices & Discounts** area. Further explanations about the creation of Projects can be found in [this](/docs/pb/masterdata/project.md) part of the DYCE documentation. ## Creating a Project Sales Order A new Sales Order can also be created (via *New Document / Sales Order*) from the contacts or customers overview. It is important that the corresponding Project (if previously created) is stored in the **Project No.** field. In addition, it is possible that a Project Sales Quote is converted to a Project Sales Order upon assignment using the **Make Order** action (via *Process*). ## Creating Project Tasks for the Sales Order After the Sales Order has been created and the positions have been entered, the Project Tasks including the Project Planning Lines for the particular activities can be created using the action **Create Service Project Tasks** (via *Home*). This is necessary so that the times for the services provided can be recorded in the further process. A detailed description of Project Tasks and the related Project Planning Lines can be found in [this](/docs/pb/sales/project-task-planning-lines.md) part of the DYCE documentation. ## Creating Work Orders from a Sales Order Work Orders can be created and managed directly from a Sales Order. The **Work Orders** action (via *Related*) opens a filtered list of Work Orders linked to the current Sales Order. New Work Orders are automatically pre-populated with ***Customer, Project, and Budget Type***. A detailed description can be found [here](/docs/pb/professional-services/creating-work-orders-from-sales-orders.md). ## Sales Order related Purchase Orders The Business Central standard basically provides for purchase orders for stock items. A manual step can be used to make reservations for Sales Order items. However, since this is somewhat cumbersome and trading goods are often also ordered on an Sales Order or Project basis, in **DYCE IT-Business Toolkit** there is a simplified way to do this. A detailed description of Sales Order-related Purchase Orders can be found in [this](/docs/ibt/sales-related-procurement.md) part of the DYCE documentation. ### Project prices for purchasing with special bid Suppliers sometimes grant discounts on individual orders, projects or customers-related purchase orders. For this, the quantity and price (and discount, if applicable) are specially negotiated. Orders for which such a project price has been negotiated must be processed separately. It is in the nature of things that there is always a Sales Order for this type of Purchase Order. A reference number (*Special Bid*) is assigned by the supplier for the project price. As a rule, this kind of special order is only processed by the supplier if the reference number is given in the order. If the reference is not included, the discount will not be granted or the order will not be processed. To create and process such orders, a reference number can be entered in the Sales Order line (in the **Special Bid** field). The reference will be added to the Purchase Order via the **Create Connected Purchase Orders** functionality (see [Create Purchase Order](/docs/ibt/sales-related-procurement.md#create-purchase-order) section) and can thus be printed. This also applies to Purchase Orders created via the Requisition Worksheet. When creating Purchase Orders, they are always unique with regards to Special Bid. Different order lines with the same reference number can be combined into one Purchase Order. :::info Reservation If an Sales Order line contains a reference number, the reservation is never made against any available stock. ::: ## Posting and billing In the meantime, Time Recordings have been entered for the Project Tasks, which have been reviewed and approved by the project manager. By posting the Time Recordings, these services are considered *shipped* (partially or completely). It is also possible that the goods receipt for the order-related retail items has already took place and the goods issue for the item has been posted. As soon as an order line is shipped, it can be invoiced. This is done either in the Sales Order via the standard **Post / Invoice** action or via the **Create Sales Invoices** batch function in the **Invoicing Services** page. The posted invoice can be sent to the customer. Depending on the settings in the Project Card (in the field **Autom. Detail Overview printing**), a Detail Overview will be created automatically and the invoice will be completed with it. The Detail Overview contains details of the invoiced order items including goodwill times. :::info Invoiced Shares The contribution of each employee to the Project's revenue is displayed using the *[Invoiced Shares](/docs/pb/controlling.md#determine-proportional-invoiced-shares)*. ::: ### Generated data and ledger entries Looking at the lines in the Project Card, it can be seen that Project Ledger Entries of the type *Sale* have been created as a result of shipping and invoicing the items. Clicking on the value in the **Invoiced (Total Price)** field opens the Project Ledger Entries, which contain the invoice number in the **Document No.** field. Using the action **Ledger Entries** (via *Project*), you can branch to the invoice, for example. When Time Recordings are posted, Project Ledger Entries of the type *Usage* are created for the human resources. These Project Ledger Entries are linked to the Time Recordings and can be viewed by clicking, for example, on the **Total Time Recordings Posted (Days)** field. The posting of Time Recordings also creates Project Planning Lines of the type *Billable*. These are opened by clicking on the **Billable (Total Price)** field. Project Ledger Entries of the type *Sale* (see above) are created when the related Sales Order items are invoiced. :::warning Invoicing of Projects With **DYCE Project Billing**, invoicing of services - in contrast to the standard of Business Central - is never done through the Project module or directly from the Project. Once the Time Recordings have been posted, several options are available for billing. These are explained in more detail in [this](/docs/pb/posting-documents.md#invoicing-of-services) section of the DYCE documentation. ::: ## Down payment invoice in Project Sales Order In the Sales Order, a down payment can be entered as an amount or as a percentage. However, in order to enter a down payment amount, the **Prepmt. Line Amount Excl. VAT** field must be displayed in the Sales Order lines. A percentage is entered either directly in the sales line (in the **Prepayment %** field) or in the *Prepayment* fast tab. In addition, the **DYCE IT-Business Toolkit** app provides a simplified way to work with a Sales Order-specific payment plan. A detailed description of Down Payments and Payment Plans can be found in [this](/docs/ibt/payment-plan.md) part of the DYCE documentation. The **Create Prepayment Invoice** action (via *Actions / Payment Plan*) creates an unposted prepayment invoice that can be posted either directly or at a later time. Posted and unposted Prepayment Invoices and Prepayment Credits can be opened via the *Related / Prepayment* menu. --- ## General Setup(3) Releasing and posting Time Recordings does not require specific user setup; appropriate [permissions](/docs/pb/setup/permissions.md) are sufficient. Posting requires **DYCE Project Billing** to be activated (see [Activation of users](/docs/pb/monetization.md#activation-of-users)). ## Projects Setup The **Projects Setup** page is where settings and defaults are made for creating and managing Projects and services (such as number series). The **Base UOM for Minute** and **Base UOM for Hour** fields are used to store the unit codes to be used for the respective time units. The system needs this information so that it can convert between the units. The **Hours per Day** field is used to specify the number of hours per working day. The **Autom. Insert Project Dimension Value** field controls whether the **Project No.** is automatically created as a new Dimension Value for each new Project. This will then be assigned to the respective Project immediately. Dimensions are usually used for evaluation purposes and are passed on from the master record (here: Project) to the related transaction data. For details on how dimensions work, please refer to this part of the Microsoft documentation. The default value for this setting is *YES*. To use this functionality, the **Dimension Code for Project** field must be filled in the Dimensions fast tab in **General Ledger Setup**. The **Description Project Task from Sales Line** field controls how Project Planning Lines for retail items (not services) are combined into Project Tasks and the description used to create these Project Tasks. For all retail items, Project Tasks (and Project Planning Lines) are created upon shipment from the Sales Order or with the *Create other Project Tasks* action. Using the standard setting **Description Project Task from Sales Line**=*NO*, one Project Task is created per **Product Posting Group** with the description of the Product Posting Group. If **Description Project Task from Sales Line** is changed to *YES*, one Project Task will be created for each Sales Order line, that is not a Service (Service Billing Type in the item is empty). The description of the Sales Order line is copied to the description of the Project Task. The following fields are used to automatically generate resource capacities: * **Create Resource Capacity Entries** determines whether resource capacities are created automatically when person resource defaults are applied. * **Create Resource Capacity Entries from** specifies the dateformula from when capacities should be created. * **Create Resource Capacity Entries until** specifies the dateformula until when capacities should be created. The number series for Projects, Time Recordings and Trips determine the principle by which new numbers are assigned. The number series to be used when creating new entries are stored here. The lookup is used to access the number series in order to select the appropriate code. For details on how number series are set up and work, please refer to this part of the Microsoft documentation. ### Project Currency {#project-currency} Business Central places a customer's currency in the Project's **Invoice Currency Code** field, while a Sales Order only carries a **Currency Code** field. A Project can only be assigned to a Sales Order or Sales Quote if the two currency codes match — a Project with a foreign currency in **Invoice Currency Code** and a Sales Order with no **Currency Code** is treated as a mismatch, even though both look "empty" for the local currency at first glance. If a Project cannot be assigned because of a currency mismatch, the error names the differing currency codes, mentions the **Project Currency** setting below, and links directly to the Project. The **Project Currency** field (*General* fast tab) controls which currency field a Project receives from a foreign-currency customer when the Project is created or its Bill-to Customer is changed. Local-currency customers are unaffected regardless of this setting — both currency fields on the Project remain blank. | Option | Behavior | |---|---| | Show Selection (default) | A prompt asks which of the two fields below to use, every time a foreign-currency customer is entered on a new Project. | | Invoice Currency Code | The customer's currency is placed in **Invoice Currency Code** (Business Central standard behavior); **Currency Code** stays blank. Choose this only if the Project will be invoiced directly, without going through a Sales Order. | | Currency Code | The customer's currency is placed in **Currency Code**; **Invoice Currency Code** stays blank. Choose this if Sales Orders will be assigned to the Project. | ### Work Order Posting {#work-order-posting} The **Use Work Order Posting** field on the *Work Orders* fast tab in Projects Setup controls how finely time recordings are tracked, released, posted and invoiced when Work Orders are used. When enabled, the Quantity to Invoice moves from the Project Planning Line level down to the individual Work Order Line, enabling per-Work-Order budget control and more granular invoice lines. **How to enable:** Open **Projects Setup** (search `Alt+Q`) → *Work Orders* fast tab → set **Use Work Order Posting** to **Yes**. Before the change is accepted, two validations run: **Consistency check:** Validates that no Work Orders or time recordings are in a state that would become inconsistent. If issues are found, the change is blocked with an error identifying the affected records. 1. **No released time recordings:** Releasing time recordings sets quantity to invoice in the project planning lines/ work order lines. Re-opening a time recording, which was released before Use Work Order Posting was changed, would try to update the "wrong" quantity to invoice. Either re-open or post all time recordings before changing Use Work Order Posting. 2. "Quantity to invoice must be empty:" As an additional check quantity to invoice must be 0 in all project planning lines budget and work order lines to avoid inconsistent data constellations. :::warning Use Work Order Posting changes the quantity to invoice field that will be used, in Project Billing Overview as well as Project Billing (Approval). * **Use Work Order Posting = Yes** makes releasing time recordings with work order in Project Billing Overview infeasible, because work order lines are not displayed. * **Use Work Order Posting = No** makes releasing time recordings without work order in Project Billing (Approval) infeasible, because project planning lines are not displayed. ::: The setting changes behavior at every step of the approval and invoicing flow: **On releasing:** | Aspect | Without Work Order Posting | With Work Order Posting | |---|---|---| | Quantity to Invoice stored on | Project Planning Line (Budget) | Work Order Line | | Capping (Budget and Fixed Price) | At Project Planning Line quantity | At Reserved Quantity per Work Order Line (and Project Planning Line quantity)| | Overbooking for Time and Material | Increases Project Planning Line quantity | Increases Reserved Quantity and Project Planning Line quantity | **On posting and invoicing:** | Aspect | Without Work Order Posting | With Work Order Posting | |---|---|---| | Project Planning Line Billable created per | Project Planning Line Budget | Work Order Line (Billing Work Order + Project Planning Line Budget combination) | | Billing Work Order Number on Project Ledger Entry | Not stored | Stored | | Invoice line granularity — without Sales Order | One line per Project Planning Line | One line per Work Order Line | | Invoice line granularity — with Sales Order | One line per Sales Order line | One line per Sales Order line | #### First-come, first-served budget allocation {#first-come-first-served} When Work Order Posting is enabled and multiple Work Orders share the same Project Planning Line (Budget) without a Reserved Quantity, the first Work Order to release its time recordings locks in its Quantity to Invoice. Subsequent Work Orders compete for the remaining budget. If the sum of all Reserved Quantities across Work Order Lines exceeds the Project Planning Line quantity, the affected fields are highlighted in red on the Work Order card as a visual warning. Use a Reserved Quantity on a Work Order Line to give that Work Order exclusive access to a specific portion of the budget (for example, a fixed-budget change request). For open or shared pools, leave the Reserved Quantity empty. Work Order Posting is most useful for projects that use Jira or Azure DevOps Work Orders, require per-Work-Order budget tracking or invoice granularity, or use Reserved Quantities. It has no effect on time recordings recorded directly on Project Tasks without a Work Order. For the full description of the approval page that uses this setting, see [Project Billing (Approval)](/docs/pb/professional-services/project-billing-approval.md). ## Suggestions for basic setups In practice, *speaking* Project names are often preferred over sequential numbering. If this is desired, the **Manual Nos.** field must be set to *YES* in the number series. In addition, to improve overall clarity, consideration should be given to making the name for Service Billing Items and resources *speaking*, as well. Specific suggestions for this can be found in the **[Item](/docs/pb/masterdata/item.md)** and **[Resource](/docs/pb/masterdata/resource.md)** master data sections of the DYCE documentation. :::tip Templates The **Item Customer Templates** contain DYCE-specific fields so they can be easily predefined for new master data records. ::: ## Sales & Receivables Setup The **Print Goodwill** field specifies whether the recorded goodwill times are printed on the Detail Overview of the invoices for Project Sales Orders. The **Print Start-End Time** field also affects the Detail Overview of invoices for Project Sales Orders. This controls the output of the activity including start and end time. In the **UOM for Fixed Price Item printing** field, the unit can be stored that will be used in the print documents for Fixed Price items. The unit stored here will be used in the print documents together with quantity 1. In this way, the actual quantities can be calculated internally for Fixed Price items, but they are not visible to the customer. Explanations about the field **Autom. Insert Project Dimension Value** can be found in [this](/docs/general/essentials/customer-dimension.md) part of the DYCE documentation. Via **[Batch Sending Documents](/docs/general/essentials/batch-sending-documents.md)** it is controlled whether the settings defined at the customer are used for batch sending of posted documents or whether the standard dialog is displayed. For the default setting *Use customer's setup* no dialog is displayed. ### Bundles For details on Bundle settings and defaults, please refer to [this](/docs/ebs/setup.md) part of the DYCE documentation. ## Profit and loss accounting (P&L) per project :::warning Disclaimer: Feature in Preview As this feature has not yet been finally evaluated on the basis of productive data, it will be treated as a *Preview* until further notice. This primarily means that it should be carefully tested *before* it is used productively by the customer. ::: Before starting to use this functionality, the field **Use Statistical Accounts** on the *Accounting* fast tab on the **Projects Setup** page must be activated. After activating the field, *Statistical Account Ledger entries* will be created and updated when the report **Calculate Proportional Invoiced Shares** is executed. To register Statistical Ledger entries, ensure that the **Statistical Account Journal Batch** on the same fast tab is selected. In this journal, the batch report **Calculate Proportional Invoiced Shares** creates lines and posts them according to the specifications (see [next section](#analysis-by-statistical-accounts)). ### Analysis by Statistical Accounts In addition to the activation (s. **[Use Statistical Accounts](#profit-and-loss-accounting-pl-per-project)**) the Statistical Accounts to which the values are to be registered must be defined in the matrix in this fast tab. It consists of five rows and four columns. In the first column, a **Service Invoicing Type** from the Project Ledger entries (see also [Non-Billable Reason](/docs/pb/time-recording.md#create-time-recordings)) is set for each line. The three remaining columns also refer to the Project Ledger entries and each represent the three different values *Total Cost*, *Total Price* and *Proportionally Invoiced* (Proportionally Invoiced Amount). The matrix fields are used to define the Statistical Accounts for which the [Statistical Account Ledger entries are registered](/docs/pb/controlling.md#profit-and-loss-accounting-pl-per-project). :::note The following matrix is fixed and it is not possible to add or delete any rows or columns. Service Invoicing Type|Total Cost|Total Price|Proportionally Invoiced |--:|--:|--:|--:| Invoicing|*Statistical Account*|*Statistical Account*|*Statistical Account* Internal|*Statistical Account*|*Statistical Account*|*Statistical Account* Good Will|*Statistical Account*|*Statistical Account*|*Statistical Account* Warranty|*Statistical Account*|*Statistical Account*|*Statistical Account* Customer Contract|*Statistical Account*|*Statistical Account*|*Statistical Account* ::: ## Reports Along with **DYCE Project Billing**, the **DYCE Essentials** app is installed. The app includes, among others, enhancements to the dataset of the following standard reports: * **Purchase** * Purchase Order * Blanket Purchase Order * **Sales** * Quote * Order Confirmation * Blanket Sales Order * Shipment * Invoice (incl. details of professional services (and subscriptions) invoiced) * Credit Memo * Reminder Furthermore, an additional DYCE layout for WORD and for RDL is supplied for each report. --- ## Job Queue(Setup) For recurring tasks, in Business Central the Job Queue is used. For details on how the Job Queue works and how to configure it, please refer to this documentation. With the installation of **DYCE Project Billing**, the following entries are automatically created in the Job Queue: * **Calculate Proportional Invoiced Shares** (report 70920904) The task is used to automatically calculate the shares of invoiced service revenue per person. The task is executed daily at 2:00 am. * **Apply Resource Person Defaults** (report 70920903) The task is used to automatically transfer the (changed) specifications for resources and, if necessary, to automatically generate the capacities. The task is intended for daily execution at 3:00 am. --- ## Permissions(Setup) This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. ## DYCE Project Billing The following three permission sets are included with the app: * **DYCEJOBBILLINGALL (DYCE Project Billing Read)** This permission set can be assigned to all users. It contains read-only permissions to app-specific data. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCEJOBBILLINGUSER (DYCE Project Billing Edit)** This permission set is for all users working with [Projects](/docs/pb/masterdata/project.md), [Time Recordings](/docs/pb/time-recording.md), and [Time & Travel Models](/docs/pb/setup/tnt-model.md). In addition, [Project Billing](/docs/pb/project-billing.md) can be used. However, editing [Resource Defaults](/docs/pb/masterdata/resource.md#human-resources), Work Time Models and [Project Types](/docs/pb/setup/project-type.md) is not intended with these permissions. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCEJOBBILLINGADMIN (DYCE Project Billing Admin)** This permission set is designed for administrators and power users who should additionally be able to create and delete [Resource Defaults](/docs/pb/masterdata/resource.md#human-resources-defaults), Work Time Models, and [Project Types](/docs/pb/setup/project-type.md). The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information about permission sets, see this part of the Microsoft documentation. ## More DYCE Apps Along with **DYCE Project Billing**, the apps **[DYCE Essentials](/docs/general/essentials/welcome.md)** and **[DYCE Easy Bundle Seller](/docs/ebs/welcome.md)** are installed. This will provide cross-app functionality such as [Bundles](/docs/ebs/bundles.md), a [Print Preview](/docs/general/essentials/print-preview.md) or the [Report Configurations](/docs/general/essentials/report-configuration.md). Three permission sets are included with the app: * **DYCEESSENTIALSALL (DYCE Essentials All)** This permission set can be assigned to all users. It includes read-only permissions to app-specific data. * **DYCEESSENTIALSUSER (DYCE Essentials Users)** This permission set is for all users working with [Bundles](/docs/pb/bundles.md). * **DYCEESSENTIALSADMIN (DYCE Essentials Admin)** This permission set is designed for Administrators and Power Users who should additionally be able to create, customize and delete [Report Configurations](/docs/general/essentials/report-configuration.md). --- ## Project Types # Categorizations of Projects The **Project Types** page defines the different types of projects. They are used for categorization and can also be used as filters - for example, in **Project Billing**. Examples can be implementation, maintenance or upgrade projects or internal projects. For each Project Type, an appropriate description should be entered in addition to a unique code. The Project Type can be selected in the Project Cards in the field of the same name. --- ## Time & Travel Models # Models for Time Recording Services can be invoiced - even without a Time & Travel Model being set up and stored in the Projects. However, the Time & Travel Model offers some features that should be considered when deciding whether to use it: * **Rounding of Time Recordings** The billable duration can be automatically rounded using the factor from the Time & Travel Model. For example, if rounding to 15 minutes is applied, the billable duration in Time Recordings will be rounded up to a full 15 minutes. * **Rounding of Project Planning Lines** In addition, the quantity to be invoiced in **Project Billing** can be rounded when Time Recordings are posted. The rounding takes place thereby regarding the sum on basis of the duration of the released and maybe posted Time Recordings which can be invoiced. * **Control of invoicing Time Recordings** In the Time & Travel Model, it is possible to control whether a Time Recording should be invoiced afterwards. This makes it easy to map activities to *Warranty* and *Goodwill* as well as internal activities. * **Preset the Non-billable Reason** If the time recording is to be only partially charged or not charged at all, the Non-billable Reason (*Warranty*, *Goodwill*, *Internal* or *Customer Contract*) can be predefined. * **Implied selection of Project Planning Lines** In Time Recording, the Project Planning Line can be selected by activity (e.g. Internal Meeting, Development, Consulting, etc.). * **Automatic take over of work type** When selecting an activity in a Time Recording, the Work Type can be populated from the Time & Travel Model line. :::info Examples of rounding Time Recordings and Project Planning Lines * For consulting (on a Time & Material basis), Time Recordings should be rounded in 5-minute increments. However, invoicing is done in 15-minute increments: **Time Recording Rounding (Minutes)**: 5, **Project Planning Line Rounding (Minutes)**: 15. * Units of work for flat-rate development services are 15 minutes. Time Recordings should be rounded and billed accordingly: **Time Recording Rounding (Minutes)**: 15, **Project Planning Line Rounding (Minutes)**: 15. * In Support, Time Recordings are automatically done to the minute via the ticket system. Time Recordings should not be rounded up during handover. Billing is done in 5-minute increments: **Time Recording Rounding (Minutes)**: 1, **Project Planning Line Rounding (Minutes)**: 5. ::: ## Setup Time & Travel Model Open the **Time and Travel Models** page. Create a new model with *New**. Enter **Code** and **Description**. In the fast tab **Time** the model lines can be created. * **Code** Enter a unique code. * **Description** The description will be displayed when selected in Time Recording. * **Work Type** Work Types can be used for further specification of times recorded by employees. * **Item No.** The **Item No.** is used to match Time & Travel Model lines with Project Planning Lines (type *Budget*). This considerably limits the selection and thus simplifies it. If an item for consulting billed by Time & Material is entered in the Project Planning Line, only model lines with the same or with no **Item No.** will be displayed when selecting the Activity. Model lines without **Item No.** are always displayed for selection. * **Billable** This field controls the default **Billable Duration**. If the flag is *NO*, the **Billable Duration** is automatically set to 0 and the corresponding Time Recordings cannot be further invoiced. * **Non-billable Reason** This field is used to control the default Non-billable Reason. If the **Billable Duration** is less than the **Duration**, the Non-billable Reason will be determined from the model line and entered. * **Time Recording Rounding (Minutes)** Specifies the rounding of the billable duration. Rounding to 15 minutes is widely used. If a user records 5 minutes in a time recording, the **Billable Duration** is automatically rounded up to 15 minutes. This does not affect the actual length of the activity. The 5 minutes are retained in the **Duration** field. Different rounding can be entered per model line for time recording. * **Project Planning Line Rounding (Minutes)** Defines the rounding for the project planning line when releasing time recordings. The rounding is applied if the **project uses the Time & Travel model** and contains a model line with the **same item as the project planning line**. Model lines with an Item No. must use the same *Project Planning Line Rounding (Minutes)*. Rounding at the project planning line level is useful when many short time recordings are created and rounding each time recording to, for example, 15 minutes does not make sense. In this case, *Project Planning Line Rounding (Minutes)* should be used to round the sum of all time entries upon approval. Translated with DeepL.com (free version) :::info Creation of a Time & Travel Model Most cases can certainly be mapped with a "standard" model. In the model there should be one line for each Service Billing Item and some lines for non-billable Time Recordings. *Internal*, *Warranty*, *Goodwill* and *Customer Contract* can each be represented via separate lines. If there are special agreements with a customer, a separate model can be created for them. This way, the time recorder does not have to know the deviating conditions and can still record his times in accordance with the specifications. ::: ## Application of the Time & Travel Model In order for the Time & Travel Model to be applied, it must be stored in the Project Cards. It can be entered in the **General** fast tab. If the Time & Travel Model is already stored in the customer, it will be applied to each new Project, but can be changed there manually if necessary. If the Time & Travel Model is stored in the Project Card, an Activity can be selected in the **[Time Recording](/docs/pb/time-recording.md)**. --- ## Surcharges(Pb) A surcharge is an additional fee levied for work performed outside of regular business hours, such as for work on evenings, nights, or holidays. This surcharge can be invoiced to the customer. It is important to note that the duration for which a surcharge is calculated (the surcharge duration) is independent of the actual time worked (attendance), as it results from a combination of the duration of the time recording and the corresponding percentage from the surcharge model. Invoicing surcharges reduces the available budget. ## Configuration and Management of Surcharges The basis for surcharges is the surcharge model, which is stored in the [master data](/docs/pb/masterdata/surcharges.md). Here, different surcharge rates can be defined for various times of day and days of the week. - **Assignment at Customer and Project Level**: The surcharge model can be stored directly on the customer card and the project card. When a new project is created, the surcharge model is automatically adopted from the bill to customer. If no surcharge model is assigned to the project, no surcharges can be determined. - **Time-based Definition**: In the surcharge model, **start and end times** can be defined for surcharges. If these fields are left blank, the surcharge applies to the entire day (e.g., for a Sunday or a holiday). - **Types of Days**: Surcharges can be defined for different **types of days**, such as working days (Mon-Fri), Saturdays, Sundays, and holidays. Working days, Saturdays and Sundays are identified directly from the date in the time recording. Holidays additionally require a **Base Calendar Code**, taken from the Project or the Resource depending on the [Base Calendar Source](/docs/pb/masterdata/surcharges.md#base-calendar-source) setting on the surcharge model. - **Percentages**: For each surcharge line, a percentage (e.g., 50% or 100%) is set. - **Deactivation**: There is a "Disable Surcharges" option in the time recording. This can be set manually to prevent surcharge calculation for a specific time recording. For projects with a "Fixed Price" billing type, this option is automatically set to "Yes" and cannot be changed by the user. ## The Surcharge Calculation Process Surcharges are calculated automatically whenever the date or duration of a time recording is changed. The calculation is based on the rules stored in the master data. 1. **Determine Type of Day**: First, the type of day for the time recording is determined (e.g., working day, Saturday, Sunday, or holiday). Please note that holidays can only be determined if the calendar selected via [Base Calendar Source](/docs/pb/masterdata/surcharges.md#base-calendar-source) has a Base Calendar Code set. 2. **Find Applicable Surcharge Model Lines**: The system searches for relevant lines in the associated surcharge model. A line is relevant if its defined times match the time recording and the surcharge percentage is greater than 0%. Please note that surcharge model lines that do not apply for the entire day can only be applied if the time recording has a start and end time (e.g., surcharges on working days from 20:00 - 0:00 can only be applied if the time recording ends after 20:00. Without a start and end time in the time recording, no surcharge can be applied). If the surcharge model line applies to the entire day, a surcharge can be determined without a start and end time in the time recording. 3. **Calculate Surcharge Duration**: The duration within each relevant surcharge model line is multiplied by the respective percentage to determine the specific surcharge duration in minutes. The sum of these individual surcharge durations results in the total **surcharge duration** for the time recording. Note: The duration considered for surcharge calculation cannot exceed the total duration of the time recording (e.g., Start 20:00, End 23:00, Break 2:59 only allows for 1 minute to be considered for the surcharge calculation). If a surcharge model line has a 0% surcharge, it is not used in the calculation and does not "consume" any duration (e.g., if the time recording overlaps with two surcharge model lines). 4. **Add to Billable Duration**: The calculated surcharge duration is added to the original **billable duration** of the time recording. The duration of the time recording itself is not changed. Only after this step is the rounding, as defined in the Time & Travel Model, applied. 5. **Time & Travel Model**: The settings from the Time & Travel Model are applied when selecting an activity. The rounding of the billable duration is applied after the surcharges have been determined. If the Time & Travel model line is marked as not billable, no surcharge is applied and the billable duration is set to 0. ## Transparency and Billing - **Visibility in Time Recording**: The "Surcharge Duration" is stored as a non-editable field in the time recording but is hidden by default. If a surcharge has been applied, the **billable duration** becomes non-editable. To edit it, surcharges must be deactivated in the time recording. - **Impact on Budget**: Surcharges increase the billable duration of the time recordings and thus directly affect the budget. (e.g., If the budget is 50 days, after billing a time recording for 1 day plus a 100% surcharge, the remaining budget is 48 days). - **Detailed Overview**: There is an option to print the surcharge model used on the detailed overview in the invoice. Time recordings for which surcharges have been calculated are marked with an asterisk here to increase transparency for the customer. This printing option can be controlled at the project level or manually when printing the invoice. - **Manual Interventions**: The "Disable Surcharges" option in the time recording allows for overriding the automatic calculation if, in a specific case, no surcharges should be calculated. - **Synchronization**: The surcharge models and surcharge data of the time recordings are synchronized with the DYCE Connect platform to ensure a consistent data basis. ## Time Zones and Surcharges For international teams, considering time zones is crucial. **DYCE Time Tracking** ensures that surcharges are always calculated based on the user's local time (based on browser settings). **The Rule: Local Time Matters!** A surcharge is applied if the user works during the hours defined in the surcharge model within their own local time zone (for which a surcharge applies). It does not matter if the main system (Business Central) is located in a different time zone. **Example:** A surcharge model defines a surcharge starting at 20:00 (8:00 PM). * **Business Central** is set to Berlin time **(UTC+1)**. * **The User** is located in San Francisco **(UTC-8)**. |No.|User time (Local)|Surcharge applied?|Time in Business Central| |:---|:---|:---|:---| |1.|11:00 - 12:00|No|20:00 - 21:00| |2.|05:00 - 06:00|No|14:00 - 15:00| |3.|20:00 - 21:00|Yes|05:00 - 06:00| * **Time Recording 1:** Even though the time in Berlin (20:00) would be eligible for a surcharge, no surcharge is calculated because the user performed the work at noon local time (11:00). * **Time Recording 3:** A surcharge is calculated because the user worked at 20:00 local time. However, in Business Central, this entry is displayed as 05:00 the following morning. :::warning Important Note for Billing On the detailed overview in the invoice, time recordings are printed exactly as they are stored in Business Central (system time). Consequently, a customer might see start and end times that differ from the actual local working hours of the reporter. ::: **Caution with subsequent changes in Business Central** Business Central stores the start and end times but not the original time zone of the user. This leads to a critical point regarding post-processing: If you modify fields such as Start/End, Duration, Date, or Resource directly in Business Central, the surcharge is automatically recalculated. Since Business Central uses its own system time zone (e.g., Berlin) as the basis for this recalculation, the result may change: * In **Example 1** above, a recalculation in Business Central would suddenly add a surcharge because the system assumes the work took place at 08:00 PM. * In **Example 3**, an existing surcharge might be removed during a recalculation in BC because 05:00 AM is not surcharge-eligible according to the system time. **Recommendation:** To maintain the correct (local) time zone, changes to time recordings from other time zones should ideally be made directly by the user in **DYCE Time Tracking** ([*s. details for Time Tracking and Time Zones*](/docs/web/tt/time-tracking/time-tracking.md#time-zones)). --- ## Time Recording Time Recordings can be easily created through **DYCE Project Billing**. However, the app is not designed to create all Time Recordings directly in the app. Rather, the app is optimized for releasing, posting and billing Time Recordings. In Time Recordings, there is an explicit distinction between **Duration** and **Billable Duration**. The **Duration** describes the actual length of the activity. The **Billable Duration** describes the duration that is to be billed in an invoice. Thus, due to goodwill or warranty, an hour of work can be recorded and still nothing billed. In order to evaluate Projects correctly, these activities must also be recorded. The reverse case is also possible. A phone call of 5 minutes can be billed as 15 minutes. Time Recordings can be viewed, created, edited and deleted in the following pages: * Time Recording * Time Recordings * Edit Time Recordings ## Create Time Recordings The **Time Recording** and **Time Recordings** pages can be accessed by searching (*Alt+Q*), among other methods. If the pages are called up in this way, all Time Recordings will be displayed unfiltered. A new line can be created here as well as a Time Recording. When creating a Time Recording, the following fields should be considered: * **Project No.** The Time Recording must be assigned to a Project. * **Project Task** Time Recordings must be assigned to a Project Task. If a Time & Travel Model has been assigned to the Project, the Project Task can be selected implicitly by selecting an Activity. Time Recordings without a Project Task will not be displayed anywhere else. Specific filtering should be applied to visualize these Time Recordings. If a Project Task is *Closed* or *Locked for Time Recording*, no new Time Recordings can be created for that Project Task. Project Tasks can also be created directly from a Customer Subscription Contract, see [Creating Project Planning Lines from Contracts](/docs/pb/professional-services/project-planning-lines.md). * **Project Planning Lines Budget** Time Recordings must be assigned to a *Budget* Project Planning Line, as invoicing via the Project Planning Line is required. If a Time & Travel Model has been assigned to the Project, the Project Planning Line can be selected implicitly by selecting an Activity. If there is exactly one *Budget* Project Planning Line in the Project Task, it is selected automatically. * **Resource No.** A resource must be assigned to a Time recording. * **Service Date** A Service Date must be entered in every Time Recording. The Service Date is also used to determine the type of day for [surcharge](/docs/pb/surcharges.md) calculation. * **Description** The entry of a (short) description is obligatory and should contain a reference to the activity. This description will be printed on the Detail Overview. * **Duration** Duration indicates the actual length of the Activity. The costs charged to the Project are based on Duration. * **Activity** Activities are used to select the Project Task and Project Planning Lines. The Activity is based on the [Time & Travel Model lines](/docs/pb/setup/tnt-model.md). From the Time & Travel Model lines, rounding, Work Types and Non-Billable Reasons can be determined. **Billable Duration** can be set. If no Activity is selected, the Billable Duration is automatically set equal to the Duration. * **Non-Billable Reason** If parts or all of the Time Recording is not to be billed, the Non-Billable Reason is automatically set to *Internal*. If an Activity is selected, the default value is determined from the Time & Travel Model line. Available values are *Internal*, *Warranty*, *Goodwill*, and *Customer Contract*. * **Status** Time Recordings can be edited if the status is *Open*. This status is automatically set when Time Recordings are created, released, posted or cancelled. * **Blanket Purchase Order** and **Blanket Purchase Order Line No.** If it is an [external resource being purchased](/docs/pb/purchase/purchase-external-resource.md), the Blanket Purchase Order and Blanket Purchase Order Line No. can be entered for the procurement. If a Blanket Purchase Order exists for the Project and the vendor associated with the resource, the fields are automatically predefined. :::info Activity In the Activity the combinations of the [Time & Travel Model line (Activity)](/docs/pb/setup/tnt-model.md), Project Task and Project Planning Line are displayed. If the Activity is entered, the Project Task and Project Planning Lines are filled in automatically. Alternatively, the values can be entered manually. If the Project Task is entered manually, the selection in the Activity is reduced. ::: If a Time Recording is created from the Project Task, from the Project or in the **Project Billing**, the Project and Project Task are automatically filled in. To do this, either navigate to the Project and open the Time Recording in the line menu of the Tasks. Alternatively, call up **Project Billing** and open the **Edit Time Recordings** page by clicking, for example, on the **Time Recordings Not Released** field. Time Recording can also be called up in the AssistEdit of the respective Project in the [Role Center](/docs/pb/first-steps.md) part *My Projects* of **DYCE Project Billing** (*Project Administrator*). --- ## Dissolution The system offers the possibility to automatically assign a validity to accruals. An expired Ledger Entry for a Prepaid Service can therefore be dissolved on a specific date. The batch processing **Expire Residuals** (action group *Process*) in the **Prepaid Service Card** is available for this purpose. In this process, an automatic pre-assignment is made for the current Prepaid Service. Alternatively, it can also be called up via the search (*Alt+Q*). For smooth operation, an entry can also be created in the Job Queue (report 70921131) for this purpose. For more details on how the Job Queue works and how to configure it, please refer to this Microsoft documentation. ## Prerequisite and setup When posting a *dissolution* for an expired accrual, appropriate Ledger Entries are created as well as populating a journal to transfer the amount to the actual revenue account. The default regarding templates and journals to be used for the dissolution is determined by the **General Journal Template Dissolution** and **General Journal Batch Dissolution** fields on the **[Prepaid Services Setup](/docs/ps/setup.md)** page (fast tab *General*). If the automatically *created* journals should also be automatically *posted*, set the related checkbox **Post auto. Dissolution** on the page mentioned above (in the *Posting* fast tab). ## Processing Batch processing **Expire Residuals** (report 70921131) is used to dissolve expired accruals. It cycles through all Ledger Entries for Prepaid Services of *Positive Adjmt.* entry type that are not marked as *Expired* and whose **Valid until** date is *lower than or equal to* the value from the request page. :::info Default value When you run the report, the **Valid until date** (in the *Options* fast tab) is directly predefined with the **Workdate** as the default value. ::: ## Ledger Entries and journals For each *dissolution*, a new Ledger Entry is created for the respective Prepaid Service. In addition, two lines are automatically created in the corresponding journal for each *dissolution*. One line is used to decrease the amount in the **deferral account** (s. **Gen. Prod. Posting Group Deferrals** in **[Prepaid Services Setup](/docs/ps/setup.md)** page) and the second is used to increase the amount in the **revenue account** (based on **General Posting Setup**). Ledger entries for a dissolution are created **when the journal lines are generated** - before the journal is posted. This allows the outstanding amount to reflect the pending dissolution immediately. These entries are initially in a state where they are not yet linked to General Ledger entry. Once the journal lines are posted, the ledger entries are updated with the corresponding G/L entry reference. :::note Deleting Journal Lines If a dissolution journal line is deleted before posting, the associated Prepaid Service ledger entry and its partner journal line are also deleted automatically. The outstanding amount is restored to its previous value. ::: --- ## Features(Ps) # Features of DYCE Prepaid Services ## Master data * Create one or more Prepaid Services per Customer * Mark items as Prepaid Service * Assign one or more Projects * Define the validity of a Prepaid Service * Set up amount and quantity budgets (in connection with [Customer Subscription Contracts](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/working-with-contracts/customer-contracts)) * Display of remaining amounts/quantities ## Sale * Offer Prepaid Services via Sales Quotes * Increase Prepaid Service * One-time charging via Sales Orders * Periodic charging and invoicing via Customer Subscription Contracts ## Billing and consumption * Assignment a Prepaid Service to a Sales Line * Assignment a Prepaid Service to a Project Task/Plan Line. * Invoicing only after consumption of the balance ## Posting * Create accruals also manually * Posting of accruals to prepayment accounts * Automatic expiration of Prepaid Services when validity is exceeded ## Prepaid Service Overview * Output of details on additions and disposals * Filter on period --- ## First steps(Ps) Start by creating an item to charge a Prepaid Service. In the [Item Card](/docs/ps/masterdata/item.md) the corresponding checkbox can be set and further information can be stored. Then you create a Prepaid Service for a customer. The easiest way to do this is via the Customer list (or the Customer card) using the **Prepaid Service** action (action group *New Document*). In the page that opens, enter a description and, if necessary, a start date and/or a validity. In addition, one or more Projects can be linked here. This is especially relevant with regard to invoicing via **[DYCE Project Billing](/docs/pb/posting-documents.md)** for services. A Prepaid Service is normally charged via a Sales Order. For this purpose, the previously created item is specified in the sales line and the Prepaid Service to be topped up is selected. Through the posting, the recharge takes place. Alternatively, a Prepaid Service can also be charged on a recurring basis (via [Customer Subscription Contracts](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/working-with-contracts/customer-contracts)). The credit can then be consumed, for example, by providing proactive and reactive services. For this, the Prepaid Service must be linked in the corresponding [Project Tasks](/docs/pb/masterdata/project-task-planning-line.md). After the time recording has been posted via **[Project Billing](/docs/pb/project-billing.md)**, an invoice can be created, respectively. The invoice is automatically posted against the balance of the Prepaid Service. If there is not enough credit in the Prepaid Service, the customer receives an invoice for the difference. Basically, when the invoice is posted, the amount accrued by charging the Prepaid Service to a prepayment account is transferred to the revenue. Remaining budget of a Prepaid Service can be dissolved after the expiration of the validity either [automatically](/docs/ps/dissolution.md) or also [manually](/docs/ps/masterdata/prepaid-service.md). Postings in connection with a Prepaid Service generate corresponding Ledger entries. These can be reviewed via the respective card. It is also possible to output these Ledger entries in the form of a [statement](/docs/ps/masterdata/prepaid-service.md). --- ## Glossary(Ps) The most important DYCE terms can be looked up in this glossary. ## A * **Accrual type** Indicates whether the Prepaid Service qualifies as one-time or recurring. ## B * **Balance line** Represents consumption which will be deducted from the respective Prepaid Service. ## C * **Consumption** Specifies the Entry Type in the Ledger Entries which is used for consuming Prepaid Services. ## D * **Deferral account** Specifies the G/L account to which the revenues from Prepaid Service item are posted initially. * **Dissolution** Specifies the Entry Type in the Ledger Entries which is created for expired Prepaid Service Ledger Entries. ## E * **Expire Residuals** Functionality that resolves all expired Prepaid Service Ledger Entries. * **Expired** Indicates expired Prepaid Service Ledger Entries. * **Entry type** Indicates the type of Prepaid Service Ledger Entries. ## G * **General Journal Template Dissolution** Specifies the default journal template for dissolving of expired Prepaid Service Ledger Entries. * **General Journal Batch Dissolution** Specifies the default journal batch for dissolving of expired Prepaid Service Ledger Entries. * **Gen. Prod. Posting Group Deferrals** Specifies the deferral account that will be used for deferring revenues from Prepaid Service items. ## L * **Ledger Entries** Represents the history of all transaction posted against a Prepaid Service. ## N * **Negative Adjustment** Specifies the Entry Type in the Ledger Entries that will be used to either cancel a recharge invoice or manually create a Prepaid Service Ledger Entry. ## O * **Outstanding Amount** Specifies the current balance of a Prepaid Service. * **One-time** Indicates one of two possible categories of a Prepaid Service (s. [Accrual type](#a)). Here a Prepaid Service item is used to sell a one-time budget (via Sales Documents) in advance and post it as a credit to a specific (customer related) Prepaid Service. ## P * **Periodic** Indicates one of two possible categories of a Prepaid Service (s. [Accrual type](#a)). Here a Prepaid Service item is used to sell a budget recurringly (via Customer Subscription Contracts) and post it as a credit to a specific (customer related) Prepaid Service. * **Positive Adjustment** Specifies the Entry Type in the Ledger Entries which is used to either top up or manually create a Prepaid Service Ledger Entry. * **Prepaid Service** Represents a place where budgets paid for in advance are collected and summed up. * **Prepaid Service Item** An item so identified is used for selling budgets in advance. ## S * **Source Document** Indicates by which document the Ledger Entries is created. * **Statement** A (print) report that shows the detailed overview of Prepaid Service Ledger Entries. ## T * **Topping up** Adding credit for later consumption to a specific Prepaid Service. --- ## Creation of Ledger Entries # Prepaid Service Ledger Entries Inflows and outflows are documented in the form of Ledger Entries for a Prepaid Service. These Ledger Entries are created automatically in various ways - firstly by posting invoices for [accruals](/docs/ps/sales/accruals.md) and [consumptions](/docs/ps/sales/consumptions.md) or by performing a [dissolution](/docs/ps/dissolution.md) for an expired entry. Ledger Entries are also created in conjunction with credit memos. Separately, Ledger Entries can also be created [manually](#create-ledger-entries-manually). Ledger Entries are called up via the action of the same name (action group *Related*) in the overview and in the card or by clicking on one of the flowfields. In addition, they can be output or printed in the form of a report ([Prepaid Service Statement](/docs/ps/masterdata/prepaid-service.md)). ## Overview of the most important fields in the Ledger Entries * The **Entry No.** indicates the sequential number of the Ledger Entry. The number is unique and is used only once. * The **Prepaid Service No.** field indicates the number of the Prepaid Service to which the Ledger Entry belongs. * The **Entry Type** indicates what type of Ledger Entry it is: - *Positive Adjmt.* is used for [topping up](/docs/ps/sales/accruals.md) the Prepaid Service. This can be achieved either via a sales document or [manually](#create-ledger-entries-manually). This entry type is also used for [balance lines](/docs/ps/sales/consumptions.md#consumption-via-sales-orders) in [Sales Cr. Memos](/docs/ps/sales/consumptions.md#adding-balance-lines-in-sales-invoices). - The *Consumption* type is used when a Prepaid Service is [claimed](/docs/ps/sales/consumptions.md) via a sales document. It is also used for [balance lines](/docs/ps/sales/consumptions.md#consumption-via-sales-orders) in [Sales Invoices](/docs/ps/sales/consumptions.md), either automatically or manually. - In this case, if an invoice for an accrual is cancelled, the entry type *Negative Adjmt.* is used. Besides, it is also possible to create *Negative Adjmt.* [manually](#create-ledger-entries-manually) and deduct them from the Prepaid Service balance accordingly. - When the batch processing for [dissolution](/docs/ps/dissolution.md) of expired accruals is executed on a specific date, Ledger Entries with the type *Dissolution* are created for the remaining open quantities and amounts. * The **Posting Date** indicates the date the Ledger Entry was created. * A date in the **Valid Until** field indicates until when the *Positive Adjmt.* is valid (see **Valid Until Dateformula** field in the [Prepaid Service Card)](/docs/ps/masterdata/prepaid-service.md#overview-of-actions-in-prepaid-services)). * When a *Positive Adjmt.* is fully consumed or dissolved, the **Expired** field is automatically set to *YES*. For Ledger Entries with the *Dissolution* entry type, **Expired** is always set to *YES*. * The information by which document an accrual was created is displayed in the **Source Document Type**, **Source Document No.** and **Source Document Line No.** fields. * **Quantity** and **Amount** indicate respectively what was added or deducted: - for the entry type *Positive Adjmt.* the amount is positive, - for the entry types *Consumption*, *Negative Adjmt.* and *Dissolution* the amount is negative. * **Remaining Quantity** and **Remaining Amount** indicate accordingly what is still available for consumption for Ledger Entry of type *Positive Adjmt.*. * **Applied Quantity** and **Applied Amount** contain what has already been consumed for Ledger Entry of type *Positive Adjmt.*. * The field **Applied to Entry No.** indicates for Ledger Entries of the type *Consumption*, *Negative Adjmt.* and *Dissolution*, to which *Positive Adjmt.* Entry Number they refer to or which accrual they clear. * The **Project No.** shows which Project was used to create the Ledger Entry. * The **VAT Gen. Bus. Posting Group** indicates the posting group used to create a Ledger entry. In the case of consumption postings, the system also checks that the posting group of the consumption matches that of the receipt to be consumed. ## Create Ledger Entries manually It is also possible to manually create Ledger Entries for Prepaid Services. This can be useful or necessary, for example, for correction purposes. After the **Prepaid Service** has been set up with all the information, Ledger Entries can be created using the **Create Ledger Entry** action (action group *Process*). The **Create Prepaid Service Ledger Entry** page displays the following fields: * **Entry Type**: This field specifies the *Type* of the Ledger Entry to be created. The choices are *[Positive Adjmt.](#overview-of-the-most-important-fields-in-the-ledger-entries)*, *[Negative Adjmt.](#overview-of-the-most-important-fields-in-the-ledger-entries)*, and *[Dissolution](/docs/ps/dissolution.md)*. * The **Item No.** indicates which [item](/docs/ps/masterdata/item.md) is used to populate the Prepaid Service. * The **Posting Date** indicates the date the Ledger Entry is created. * In the **Valid Until** field, a date can be specified until which the Ledger Entry to be created is valid. * The **Amount** field is used to specify the amount with which the Ledger Entry is to be created. This only applies to Prepaid Services with **Accrual**=*One-time*. * In **Quantity** the quantity is specified with which the Ledger Entry is to be created. This only applies to Prepaid Services with **Accrual**=*Periodic*. :::info Item and Validity The **Item No.** field can only be set in conjunction with the **Entry Type** *Positive Adjmt.*. If *Positive Adjmt.* is selected as the **Entry Type**, the field will contain the Item No. of the last accrual for the Prepaid Service as the default value. If it does not yet contain an accrual, the field is empty and *has* to be filled. In both cases it is possible to open an overview of items marked as **Prepaid Service** and select the desired item. If the **Valid Until Dateformula** field is set on the Prepaid Service, the value will be calculated based on the Posting Date. In this case, the field is not editable. Otherwise, the field is initially blank and can be edited. ::: --- ## Item # Prepaid Service Items Before an item can be used to top up a Prepaid Service (field **Prepaid Service** on the *General* fast tab on the Item card), it must meet the following requirements: * **Item Type** The item's **Type** must be set to *Non-Inventory*. The **DYCE Prepaid Service** field cannot be enabled on items of any other type (e.g., Inventory or Service), and once the field is enabled, the item's Type can no longer be changed away from Non-Inventory. * **No combination with Service Billing** The item's **[Service Billing Type](/docs/pb/masterdata/item.md)** (from **DYCE Project Billing**) must be set to *None*. An item cannot be used simultaneously as a service-billing item and as a Prepaid Service item. * **No combination with Bundles** The item must not be flagged as a **[Bundle](/docs/ebs/bundles.md#master-data-for-bundles)** (from **DYCE Easy Bundle Seller**). Prepaid Service items and bundle items are mutually exclusive. * **Interaction with Subscription Billing** If the **DYCE Recurring Prepaid Services** app is installed alongside **DYCE Prepaid Services**, an additional constraint applies to the item's **Subscription Option** field (**[Microsoft Subscription Billing](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/masterdata/items)**): it must be set to *Sales without Subscription*, *Subscription Item*, or *Sales with Subscription* — any other value is rejected once the item is flagged as a Prepaid Service. If the item also carries a Subscription Package, that package's lines **Invoicing via** must be set to *Contract*. For items backing a periodic (recurring) Prepaid Service, **Subscription Option** must be set to **Subscription Item**. Note: This check is only enforced when the **DYCE Recurring Prepaid Services** app is active; without it, **DYCE Prepaid Services** app does not evaluate the Subscription Option field. * **Distinct posting group** The item's **Gen. Prod. Posting Group** must be different from the **Gen. Prod. Posting Group Deferrals** configured in the **Prepaid Services Setup**. This separation is required so that top-up postings can be distinguished from deferral postings in the general ledger. :::warning One-Time and Recurring Prepaid Services Items with **Subscription Option**=*Sales without Subscription* and therefore without assigned [Subscription Package](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/masterdata/service-commitments) are used for *one-time* recharge of a Prepaid Service. Charging is done e.g. by invoicing the sales order. Items with **Subscription Option**=*Subscription Item* and related [Subscription Package](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/masterdata/service-commitments) are used for *recurring* recharge of a Prepaid Service. The **Prepaid Service No.** is transferred from the Sales Line to the Subscription Line. For manually created Subscriptions, the number can be entered manually in the Subscription Line. Charging of the respective Prepaid Service is done by posting the contract invoice. ::: ## Purpose Items set as **Prepaid Service** can be used to top up **[Prepaid Services](/docs/ps/masterdata/prepaid-service.md)**. Either Sales documents or Customer Subscription Contracts are available for this purpose. Charging via a sales document (usually a Sales Order) is a one-time transaction. In this case, the revenues are handled as some kind of prepayment and therefore initially deferred. Customer Subscription Contracts, on the other hand, charge a Prepaid Service on a recurring basis, whereby the revenues are also deferred in the same way. In both cases, a subsequent utilization results in the transfer of the respective amount to the corresponding revenue account. Further details on the deferrals and posting to deferral accounts are explained in more detail [here](/docs/ps/sales/accruals.md). --- ## Prepaid Service # Prepaid Services In the **Prepaid Service Card** information and details about the specific Prepaid Service can be entered. Among other things, the current status of the credit can be seen here. After the customer has *topped up* a Prepaid Service, it can be *used* as needed. A new **Prepaid Service** can be created with the **New** action both via the list and the card and via the action of the same name on the Customer (action group *New Document*). The overview of all Prepaid Services can be accessed via the search (*Alt+Q*). In addition, the card provides further details (see [next section](#overview-of-the-fields-of-the-prepaid-services)). ## Overview of the fields of the Prepaid Services *The **Customer No.** and **Customer Name** fields respectively indicate the number and name of the customer for whom a Prepaid Service is created. * In the **Description** field, provide a reasonably detailed description of the Prepaid Service. The description is printed in the details output. * For an explanation of **Accrual**, see [Different types of accruals](#different-types-of-accruals) below. * The **Type** field controls whether a Prepaid Service consists of an *amount* or a *quantity*. Prepaid Services of type *Amount* are often used as a budget for services for which it is not yet known in advance which services will be used later. Prepaid Services of the type *Quantity*, on the other hand, are used as units of time, e.g. as *hours for support services* or *number of tickets per month*. * **Start Date** and **End Date** can be used to record the start and end of the Prepaid Service. Both of these entries are optional. * The **Closed** field indicates that the Prepaid Service is already closed. It is hidden by default in overviews. * **Outstanding Amount (LCY)** indicates the amount still available in local/client currency (applies to [One-time Prepaid Services](#different-types-of-accruals)). * **Posted Usage Amount (LCY)** displays the amount already consumed in local/client currency (applies to [One-time Prepaid Services](#different-types-of-accruals)). * **Outstanding Quantity** indicates the quantity still available (applies to [Periodic Prepaid Services](#different-types-of-accruals)). * **Posted Usage Quantity** displays the quantity already consumed (applies to [Periodic Prepaid Services](#different-types-of-accruals)). * The optional *Dateformula* in the **Valid until Dateformula** field indicates the validity of the Prepaid Service. In order for the specification to be taken into account for a new receipt, the value must be specified before the receipt is created. If the field is empty, new additions are valid for an unlimited time. * The *Dimension Value* used for postings around the Prepaid Service is specified in the **Dimension Value for Prepaid Service** field. In the **[Prepaid Services Setup](/docs/ps/setup.md)**, the **Auto-insert Dimension Value for Prepaid Services** field controls whether the custom number is automatically created as a new Dimension Value for each Prepaid Service. * The **No. of Projects assigned** field specifies the number of assigned **Projects** for Prepaid Service. It is possible to assign multiple Projects to a Prepaid Service. Clicking on the field opens the **Assigned Projects for Prepaid Service** page. Here you can assign one or more Projects to the Prepaid Service. ## Overview of actions in Prepaid Services In the action group *Process* the actions **[Expire Residuals](/docs/ps/dissolution.md#processing)** and **[Create items](/docs/ps/manual-ledger-entry.md#create-ledger-entries-manually)** are available. When the **Expire Residuals** action is called, batch processing is performed for the release of *expired* items. This is always useful when the already expired remaining amounts and quantities are to be released explicitly for this Prepaid Service. This functionality can also be [automated](/docs/ps/setup.md#job-queue). Please refer to the link above for more information on this action. Via the action **Create Ledger Entry** there is the possibility to create them manually. This may be necessary in exceptional cases for correction purposes. For more details on this action, please refer to the link above. **Prepaid Services Statement** (action group *Reports*) provides a detailed overview of the Ledger Entries (inflows and outflows) that form the basis for the **Outstanding Amount** or the **Outstanding Quantity** of the Prepaid Service. The call is available both in the overview and in the card. Alternatively, you can enter the term *Prepaid Services Statement* in the search function (*Alt+Q*) and run the report. ## Different types of accruals Prepaid Services are differentiated based on **type** ([see above](#overview-of-the-fields-of-the-prepaid-services)). This also affects the handling of the related revenue entries. For both types, revenue that has not yet been *used* must be deferred. The manner differs based on the following selection: * **One-time** An [item](/docs/ps/masterdata/item.md) identified as a *Prepaid Service* is sold to a customer once. The amount from the sale is available as a credit in the Prepaid Service. Until the credit is used, the amount is treated as a kind of prepayment. * **Periodic** Prepaid Services marked as *Periodic* are invoiced via **[Customer Subscription Contracts](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/working-with-contracts/customer-contracts)**. The credit is topped up when the contract invoice is posted. Deferral are handled as explained [here](/docs/ps/sales/accruals.md) in more detail. This selection can only be made if **[Microsoft Subscription Billing](https://learn.microsoft.com/en-us/dynamics365/business-central/srb/welcome)** is also used. :::info Possible combinations **One-Time** Prepaid Services can only be set up as *Amount*, while **Periodic** Prepaid Services can be set as both *Amount* and *Quantity*. ||One-time|Periodic| |:--|:--|:--| |Amount|x|x| |Quantity||x| ::: --- ## Purpose(Ps) # Purpose and benefit of DYCE Prepaid Services A customer approaches his contact person in Sales and wants to buy some services in advance and retrieve them at a later time. It is okay for him to pay in advance as well, as long as he is able to use this budget for any services in the future. The Sales user creates a sales quote and sends it to the customer via email. After approving, she creates a sales order, ships and posts it and loads thereby the amount into the customer's Prepaid Service. After the Prepaid Service is topped up, the customer expects to receive a statement on a regular (e.g. monthly) basis. Furthermore, the customer would like to use up the budget within the Prepaid Service and expects to receive regular invoices once Prepaid Service is exceeded. The customer wants this budget to be used for services fulfilled regarding one project in particular. The user in Sales department therefore checks the Prepaid Services set up for the customer. Additionally, she checks whether the correct projects are assigned to the Prepaid Service in general in order to make sure that future postings will be correct. She finds that the Prepaid Service is not yet linked to the project the customer would like to use the budget for. In the Prepaid Service she therefore selects the appropriate project from the list and assigns it to the Prepaid Service. After some time, the customer asks her to assign an additional project to this Prepaid Service, in order to use up the budget for these services, too. She assigns this additional project to the same Prepaid Service. The key account manager wants to give away a goodie for this customer which shall be applied on the next occasion. He opens the Prepaid Service and wants to top up it with some additional amount. The user expects to have a page where he can provide information about the amount for topping up and posting dates. During the project, the customer consumes different services and buys some retail items. Both services and items are to be settled with the Prepaid Service. At the end of each month, the customer receives a statement of the outflows and the current status of the budget of the Prepaid Services, as well as an invoice with a zero amount. The invoices and the statement are prepared by employees in the internal sales department. Whether the invoice amount is covered by the Prepaid Service is to be checked automatically. Consumed services and sold hardware are automatically billed against these Prepaid Services. The employees then send the documents. From time to time, the customer contacts his key account manager and needs an info regarding the balance for all his Prepaid Services for the whole current year (or any specified period). Additionally, he wants to see details for each of his Prepaid Services. The key account manager uses the Prepaid Service statement report which will show a balance of each Prepaid Service with details of entries. He sends this report to the customer via email. At the beginning of the project, customer and key account manager agreed that a remaining amount (below a certain threshold) will expire after some time. Three months after the end of the project the key account manager checks if there is an outstanding amount in the Prepaid Service. Since it is within the agreed boundaries, this amount needs to be transferred from prepayment account to revenue account. The key account manager asks a colleague from finance department to take care of this. In order to do so, the user from finance department opens Prepaid Service card and calls an action to dissolve the remaining amount. It will be transferred into the General Journal batch which is defined in the setup. In addition, you can specify here whether the entries in this worksheet are subsequently also posted automatically. --- ## Accruals # Sales process Create a Sales Invoice or Sales Order (hereafter *sales document*) containing a Prepaid Service item to charge a Prepaid Service with. This sales document represents the contractual agreement with the customer. Prepaid Service items can also be used in advance in Sales Quotes and thus initially offered to the Customer. They are printed and can be shipped from the Sales Order. Whether or not the sales document is also used for billing purposes depends on whether the prepaid service is of the one-time or recurring type. Both variants are available. They are explained in more detail in [this section](/docs/ps/masterdata/item.md). ## Topping up One-Time Prepaid Services A **Prepaid Service** can be topped up once to store an amount as credit for a customer. If an item identified as a **Prepaid Service** is used in a sales document, the **Prepaid Service No.** to be increased must be selected in the sales line prior to posting. In this case, the **Quantity** for this sales line is always predefined as *1* and cannot be changed. The increase is then done by the subsequent invoicing. ## Topping up Recurring Prepaid Services A **Prepaid Service** can also be topped up on a recurring basis, for example, to provide a specific amount of services per period (e.g., support hours per month). In this case, an item marked as a **Prepaid Service** can also be used in a sales document, from which a subscription is created later in the process. Here, too, the **Prepaid Service No.** must be specified in the sales line before the transaction is posted. This **Prepaid Service No.** is transferred to the subscription line (in the subscription). Alternatively, the subscription can also be created manually, and the **Prepaid Service No.** can be selected directly in the subscription line. Creating and posting the contract invoice for the customer subscription contract triggers the posting or crediting of the **Prepaid Service**. ## Deferrals for Prepaid Services When posting an invoice for a Prepaid Service, the system always automatically performs deferrals; that is, the amount is posted not to a revenue account but to an **deferral account**. This applies to both one-time and recurring Prepaid Services. The deferred amounts are later transferred to a **revenue account** when the consumption is posted. General ledger accounts are controlled using the General Posting Setup; see the next section for more information. ### Posting and Account Determination for Deferrals and Releases If an item marked as **Prepaid Service** is used in a document, the **Gen. Prod. Posting Group** in the sales line is replaced based on the setting in the **Gen. Prod. Posting Group Deferrals** field from the [Prepaid Services Setup](/docs/ps/setup.md) is used. The customer’s Gen. Bus. Posting Group (depending on **Invoiced to/Sold to VAT Calculation** in the **General Ledger Setup**, fast tab *General*) serves as an additional criterion. The deferral account is determined based on these two criteria. When the invoice is posted, the amount of the sales line is posted to the determined deferral account, and a Ledger Entry (**Posting Type**=*Positive Adjmt.*) is created for the Prepaid Service, thereby crediting it accordingly. Once the Prepaid Service has been topped up, it can be used or consumed. Further details on the *consumption* of Prepaid Services are explained in more detail [here](/docs/ps/sales/consumptions.md). :::warning Deferrals for Recurring Prepaid Services For contract lines with a **Prepaid Service No.**, no contract deferrals are created based on the Customer’s subscription contract; this is always done exclusively through the [Prepaid Services Setup](/docs/ps/setup.md). When assigning a **Prepaid Service No.** in a contract or subscription line, the **Create Contract Deferrals** field is always automatically set to *No* and cannot be changed manually. This prevents duplicate deferral entries and revenue recognition. The general ledger account for posting the contract invoice is determined based on the **Gen. Prod. Posting Group for deferrals** from the Prepaid Services Setup, not based on the default customer contract account. The transfer from the deferral account to the revenue account occurs exclusively through the *consumption* of the Prepaid Service - either by posting consumption invoices or by running the **Release Remaining Balances/Quantities** report. ### Subscription Option and Subscriptions In contrast to items for charging [one-time](/docs/ps/masterdata/prepaid-service.md#different-types-of-accruals) **Prepaid Services**, items for charging [recurring or periodic](/docs/ps/masterdata/prepaid-service.md#different-types-of-accruals) **Prepaid Services** must be set to create a subscription including lines. Therefore, *Subscription Item* must be selected in the **Subscription Option** field for the item and a suitable subscription package must be assigned. The subscription package must * have a line with **Partner**=*Customer*, which * is invoiced via contract (**Invoicing via**=*Contract*), * the **Invoicing Item No.** field is left empty (so that the item itself is used for invoicing) and * the **Calculation Base %** should be *100*. In addition, it should be sensibly marked as *Standard* for the item. For more information on items and subscription packages, please refer to the relevant parts of the documentation for Microsoft Subscription Billing. ## Manual creation of Ledger Entries Prepaid Services can also be manually topped up using the **Create Ledger Entry** action (action group *Process* on the [Prepaid Service Card](/docs/ps/masterdata/prepaid-service.md)). For more details, see [this](/docs/ps/manual-ledger-entry.md#create-ledger-entries-manually) part of the DYCE documentation. --- ## Consumptions # Consuming Prepaid Services **Prepaid Services** can be used or consumed in several ways. On the one hand, they can be used in [Sales Orders](#consumption-via-sales-orders) or in [Sales Invoices](#adding-balance-lines-in-sales-invoices). On the other hand, services (which have no connection to a Sales Order) can also be charged against a **Prepaid Service** via [Projects](/docs/ps/sales/working-with-projects.md#project-tasks-and-project-planning-lines). ## Consumption via Sales Orders When consuming via Sales Orders, items are added to the order which are not marked as **Prepaid Service**. At the same time, the **Prepaid Service** itself to be charged or consumed is selected in the **Prepaid Services No.** field. The selection is thereby filtered on the basis of the customer (**Sell-to Customer No.**) from the Sales Order. When **Posting** (*Invoicing*) the Sales Order, one or more new lines are automatically created on the generated invoice as *balance lines*. These balance lines represent the *consumption* that will be deducted from the specified Prepaid Service. The balance line(s) will be created at runtime and the fields will be filled automatically. At the same time, a Ledger Entry associated with the balance line (with **Entry Type**=*Consumption*) is created for Prepaid Services and these are reduced accordingly. ### Transfer of deferrals to revenue account For balance lines, the **Gen. Prod. Posting Group** is set based on the setup (**Gen. Prod. Posting Group Deferrals** field in [Prepaid Services Setup](/docs/ps/setup.md)), so that the amount is rebalanced - based on the General Posting Setup - with the posting to the **deferral account**. At the same time, the item's **Gen. Prod. Posting Group** will post to the **revenue account** in the associated invoice line, as usual. :::info The quantity for balance lines is always a fixed negative value of *-1* and cannot be changed. Regardless of the number of sales lines and items used, only *one* balance line is ever created per **Prepaid Service No.**. ::: ## Adding balance lines in sales invoices In addition to the automatic creation of balance lines, they can also be added manually to a Sales Invoice that has not yet been posted, if required. To do this, a value must be specified in at least one invoice line in the **Prepaid Service No.** field. With the execution of the action **Add Prepaid Service Balance Line** (execute via action group *Actions/Functions*), these *balance line(s)* will be created. At the same time, corresponding Ledger Entries are created for the **Prepaid Service**, so that the residual budget is always updated immediately. Deleting a balance line also deletes the related Ledger Entry. The function for adding balance lines is basically also available in Sales Credit Memos that have not yet been posted. However, the purpose here is primarily to restore a document created by the system. :::info Balance lines for Prepaid Services The action is always executed for all document lines. All **Prepaid Services** are taken into account. ::: :::warning Change of balance lines Once balance lines have been created, they cannot be modified. When balance lines are deleted, the corresponding Ledger Entries are also deleted. ::: ## Manual creation of ledger entries Prepaid Services can also be reduced manually using the **[Create Ledger Entry](/docs/ps/manual-ledger-entry.md#create-ledger-entries-manually)** action (action group *Process* on the [Prepaid Service Card](/docs/ps/masterdata/prepaid-service.md)). Further details on manual creation of Ledger Entries are explained in more detail in [this part](/docs/ps/manual-ledger-entry.md#create-ledger-entries-manually) of the DYCE documentation. --- ## Working with Projects(Sales) The **DYCE Prepaid Services** app is an extension for **[DYCE Project Billing](/docs/pb/welcome.md)** and enables the use of **Prepaid Services** in combination with Projects. In **DYCE Project Billing**, [Projects](/docs/pb/sales/working-with-sales-docs.md) are used for time recording and billing of all types of services and the integration with Sales. Background on how to build and set up Projects is explained in [this](/docs/pb/masterdata/project.md) part of the DYCE documentation. ## Creating Project Tasks from the Sales Order After a Sales Order has been created which includes a [Service Billing Item](/docs/pb/masterdata/item.md) and the **Prepaid Service No.** specified, the **Create Service Project Tasks** action (via action group *Home*) can be used to create the Project Tasks including the Project Planning Lines for the respective activities. The prerequisite for calling up the action is that the Sales Order contains a link to a **Project**. ### Project Tasks and Project Planning Lines [Project Tasks and Project Planning Lines](/docs/pb/masterdata/project-task-planning-line.md) form the basis for time recordings and the related billing of services. Information on **Prepaid Services** can also be provided this way. On the **Create Project Tasks** page, the lines with Service Billing Items are displayed, including the **Prepaid Service** to be used. For each **Project Task**, a **Project Planning Line** is created with the **Line Type** *Budget* and the respective **Prepaid Service No.**. The remaining fields in the Project Tasks and Project Planning Lines are populated in the usual manner. When **Time Recordings** are posted, another Project Planning Line is created with **Line Type** *Billable* based on the Budget Project Planning Line and including **Prepaid Service No.**. Whether the **Prepaid Service No.** is consumed (via a balance line) is determined per Time Recording, not per invoice. Each Time Recording has a **Service Date**. This date is compared to the validity period of the **Prepaid Service Ledger Entry**. The invoice's own **Posting Date** does not matter. If the Service Date is inside the validity period and credit is still available, the amount uses up the credit and is covered by the balance line. If the Service Date is outside the validity period, the amount is billed normally instead, and the credit is not used. An invoice can have Time Recordings both inside and outside the validity period. In that case, the balance line only covers the part inside the validity period, and the rest stays on the invoice as a normal amount. Based on the balance line, **Prepaid Service Ledger Entries** are created and linked to the posted invoice. This works the same way for invoices created through sales orders and for invoices not linked to a Sales Order. It also works the same way for every Prepaid Service **Type** (*Amount* or *Quantity*) and **Accrual** (*One-time* or *Periodic*). For more details on Project Tasks and Project Planning Lines, see [this](/docs/pb/sales/project-task-planning-lines.md) part of the DYCE documentation. :::info No credit available If none of the Time Recordings on an invoice have a Service Date inside the validity period, no balance line is created. A notification informs the user that no credit is available. ::: :::tip Prepaid Services in Project Tasks and Project Planning Lines In addition to automatically creating **Prepaid Service No.** in Project Tasks and Project Planning Lines, you can also specify them manually. ::: --- ## Setup(Ps) # General Setup On the **Prepaid Services Setup** page, general settings and default values are made for creating and managing Prepaid Services. In the *General* fast tab, there are several fields available for this purpose. The **Automatic Insert Prepaid Service Dimension Value** field controls whether the *No.* of the Prepaid Service is automatically created as a new Dimension Value for each new Prepaid Service. Dimensions are usually passed on from the master record (here: Prepaid Service) to the related transaction data. For details on how dimensions work, see this part of the Microsoft documentation. The default value for this setting is *YES*. To use this functionality, the **Dimension Code for Prepaid Services** field in the *Dimensions* fast tab in **General Ledger Setup** must be populated. It is mandatory that the **Gen. Prod. Posting Group Deferrals** field be filled. The Gen. Prod. Posting Group for the deferrals of revenues from the sale of Prepaid Services is specified here. If necessary, it is useful to create a new Gen. Prod. Posting Group for this purpose. The G/L accounts to be used are specified in the same way as in the Business Central standard via the General Posting Setup page. Create entries here for the combinations of (new) Gen. Bus. Posting Group and the Gen. Bus. Posting Groups and assign the appropriate G/L accounts. The **General Journal Template Dissolution** and **General Journal Batch Dissolution** fields control which General Journal Template and General Journal Batch will be used by default for the [dissolution](/docs/ps/dissolution.md) of the expired Prepaid Services. On the *Numbering* fast tab, the **Prepaid Service Nos.** field specifies which number series is used to assign numbers for Prepaid Services. On the *Posting* tab, the **Post manual Dissolution** and **Post auto. Dissolution** control whether the General Journals for automatically and manually created [dissolutions](/docs/ps/dissolution.md#ledger-entries-and-journals) are automatically posted directly. ## Job Queue The Job Queue is available in Business Central for recurring tasks. For details on how the Job Queue works and how to configure it, please refer to this Microsoft documentation. With the installation of **DYCE Prepaid Services**, no entries are *automatically* created in the Job Queue, but it is possible to have the dissolution of the remaining amounts and quantities also performed automatically. In this case, please create a new entry for the **Expire Residuals** report (70921131). For more details on this functionality, please refer to *[this](/docs/ps/dissolution.md)* section. ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. The following three permission sets are included with the app: * **DYCEPREPAIDSERVALL (DYCE Prepaid Services Read)** This permission set can be assigned to all users. It contains read-only permissions to app-specific data. The same permissions extend the standard permission set D365 READ (Dyn. 365 Read access all). * **DYCEPREPAIDSERVUSER (DYCE Prepaid Services Edit)** This permission set is for all users who work with Prepaid Services, charging them and posting consumption. However, access to the setup is not provided with these permissions. The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCEPREPAIDSERVADMIN (DYCE Prepaid Services Admin)** This permission set is designed for administrators and power users who should additionally be able to customize the setup. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). The permission sets build on each other and contain the respective underlying set. For more information on permission sets, see this part of Microsoft documentation. --- ## Prerequisites # Prerequisites for DYCE API Connector for Dataverse :::warning Caution The standard Microsoft Dataverse Connection must not be enabled when using **DYCE API Connector for Dataverse**. Enabling both can lead to duplicate data and synchronization conflicts. ::: Before installing **DYCE API Connector for Dataverse**, ensure you have the following requirements in place: * Administrative access to your Microsoft Entra ID (formerly Azure AD) * An active Azure Subscription * Administrative privileges in Business Central * Access to your Dataverse/Dynamics 365 Sales environment * Coordination with wysa for SalesCentral and DataBridge deployment The setup process involves three main components: 1. **DYCE API Connector for Dataverse** - The AppSource app providing API pages in Business Central 2. **SalesCentral** - wysa's sales solution for process alignment 3. **DataBridge** - Azure-hosted mapping and synchronization engine ## App Registration in Microsoft Entra ID To enable secure communication between Business Central and Dataverse, you need to create two app registrations in Microsoft Entra ID. ### Business Central App Registration 1. Navigate to **Azure Portal** > **Microsoft Entra ID** > **App registrations** 2. Click **New registration** to create a new app registration 3. Configure the following **API permissions**: * **Business Central API.ReadWrite.All** (requires admin consent) * **Business Central Automation.ReadWrite.All** (requires admin consent) * **User.Read** (delegated permission) 4. An administrator must grant consent for the Business Central permissions 5. Note the **Application (client) ID** for use in Business Central setup ### Dataverse/Sales App Registration 1. Create a second app registration following the same process as above 2. Configure the following **API permission**: * **User.Read** (delegated permission) 3. Note the **Application (client) ID** for use in SalesCentral setup To generate a client secret for either of the app registrations: 1. Navigate to **Azure Portal** > **Microsoft Entra ID** > **App registrations**. 2. Select the app registration for which you want to create a secret. 3. Go to **Certificates & secrets** > **Client secrets**. 4. Click **New client secret**. 5. Add a description and choose an expiration time, then click **Add**. 6. Copy the **Value** of the secret immediately. This is the only time you'll be able to view it. Store it securely, as you will need it for configuring the connection between Business Central and Dataverse/SalesCentral. --- ## Business Central # Setup in Business Central After installing **DYCE API Connector for Dataverse** from AppSource, complete the following setup steps in your Business Central environment. ## Marketing Setup To ensure proper synchronization, the **Business Relation Code for Customers** must be configured. 1. **Navigate to Marketing Setup** * Use *TellMe* search (Alt+Q) and open **Marketing Setup**. 2. **Configure Business Relation Code** * Ensure the **Bus. Rel. Code for Customers** field is populated. * This setting is required for linking contacts to customers. ## Microsoft Entra Application Setup 1. **Navigate to Microsoft Entra Applications** * Use the search function in Business Central (Alt+Q) * Search for "Microsoft Entra applications" 2. **Create New Application Entry** * Click the **+ New** button * Enter the **Client ID** from your Entra App Registration created for Business Central * Add a meaningful **Description** (e.g., "DYCE API Connector for Dataverse Integration") 3. **Grant Consent** * Click the consent button to authorize the application * **Note:** You must have administrative rights to grant consent. * You will be redirected to Microsoft's consent page * Sign in with your Microsoft account and approve the permissions * Confirm successful authentication 4. **Enable the Application** * Change the **State** field from **Disabled** to **Enabled** * This activation creates a system user for the integration ## Permissions Permissions stretch across Business Central and Microsoft Entra. ### Business Central Two permission sets are included in the app: * **DYCEACDUSER (DYCE ACD Entra User)** This permission set can be assigned to all users working with contacts and opportunity elements and who should be able to post sales documents. Furthermore, it contains read-only permissions for some master data tables. * **DYCEACDOPPELEMENTMGT (DYCE ACD Opp. Elements)** This permission set has a narrowed scope compared to DYCEACDUSER. It is meant for all users who work with opportunities in general. For more information on permission sets, see this part of the Microsoft documentation. ### Microsoft Entra The Microsoft Entra application requires certain permission sets to access the required API pages: 1. **Navigate to the User Permission Sets** * Open the Microsoft Entra application record * Access the **User Permission Sets** section 2. **Assign Required Permissions** Add the following permission sets: * **DYCE ACD Entra User** (ID: 72077780) - Allows access to all API Connector for Dataverse specific API pages - Includes permissions for opportunity elements, contacts and sales data - Includes automatically: `D365 SALES`, `D365 OPPORTUNITY MGT`, and logging permissions **D365 BASIC** - Enables standard access to Business Central basic functions - Required for basic system operations These permission sets ensure that the integration can read and write data through the API pages while maintaining security boundaries. --- ## DataBridge and SalesCentral # Integration with SalesCentral and DataBridge The complete integration solution includes wysa's SalesCentral and DataBridge components described in this chapter. ## SalesCentral {#SalesCentral} [SalesCentral Documentation](https://salescentral.docs.dsyr.de/databridge/introduction.html) SalesCentral is wysa's specialized sales solution that ensures business processes are properly aligned between Business Central and Dynamics 365 Sales. It provides: * Standardized sales workflows across both platforms * Process consistency and data integrity * Enhanced sales functionality and user experience ## DataBridge {#DataBridge} [DataBridge Setup Documentation](https://databridge.docs.dsyr.de/setup/index.html) DataBridge is deployed in your Azure tenant and serves as the orchestration engine for the integration: * **Mapping Configuration** - Defines how data flows between systems * **Synchronization Jobs** - Manages automated data exchange * **Monitoring and Logging** - Tracks integration health and performance :::info Setting up SalesCentral and DataBridge **Important:** Setup and configuration of SalesCentral and DataBridge is always performed by wysa as our certified partner. Please coordinate directly with wysa for: * DataBridge deployment in your Azure tenant * SalesCentral configuration and customization * Custom mapping requirements and modifications * Integration testing and validation procedures ::: --- ## Opportunity Elements - Job Queue # Opportunity Elements - Job Queue Setup To ensure Opportunity Elements are automatically updated when item dimensions change, you should set up two tasks for the job queue. ## Why Job Queues? Opportunity Elements are generated from item dimensions. When item master data changes, the Opportunity Elements must be updated: **Scenarios for updates:** * A new item is created with a new dimension combination - new Opportunity Elements must be created. * An item receives new Default Dimensions - new Opportunity Elements must be created. * Dimension Values on items are changed - Opportunity Elements must be updated. * Default Dimensions are removed from items - unused Opportunity Elements must be deleted. Using job queues, the system updates Opportunity Elements automatically in the background. This requires two tasks for the job queue: ### 1. Update Opportunity Elements Creates new Opportunity Elements when new dimension combinations are added to items. ### 2. Delete unused Opportunity Elements Deletes Opportunity Elements that no longer exist in the item master data. :::info Note When installing the app, these job queue entries are created automatically. They only need to be checked and adjusted if necessary. ::: ## Check Job Queue Entries 1. Search for **Job Queue Entries**. 2. Open the list. 3. Search for the following entries: * **Update Opportunity Elements from Item Changes** (Codeunit 72077784) * **Delete Unused Opportunity Elements** (Codeunit 72077784) ## Job Queue Entry 1: Update Opportunity Elements ### Recommended Settings | Field | Value | Explanation | |------|------|-----------| | **Description** | Update Opportunity Elements from Item Changes | Automatically generated name | | **Object Type to Run** | Codeunit | | | **Object ID to Run** | 72077784 | Codeunit DYCEACDOppElementManagement | | **Parameter String** | OPPELEMENTUPDATE | Internal parameter for update operation | | **No. of Minutes between Runs** | 5 | Runs every 5 minutes | ### What does this Job Queue entry do? 1. The job queue runs every 5 minutes. 2. All items and their Default Dimensions are scanned. 3. For every new combination of the configured dimensions, an Opportunity Element is created. 4. Existing Opportunity Elements are not duplicated or deleted. **Example:** * Current: HP-Purchase, HP-Rent, Dell-Purchase * New item is created: Dell Latitude with dimension Dell-Rent * Job runs - Opportunity Element "Dell-Rent" is created ## Job Queue Entry 2: Delete unused Opportunity Elements ### Recommended Settings | Field | Value | Explanation | |------|------|-----------| | **Description** | Delete Unused Opportunity Elements | Automatically generated name | | **Object Type to Run** | Codeunit | | | **Object ID to Run** | 72077784 | Codeunit DYCEACDOppElementManagement | | **Parameter String** | OPPELEMENTDELETEUNUSED | Internal parameter for delete operation | | **No. of Minutes between Runs** | 60 | Runs every 60 minutes | ### What does this Job Queue entry do? 1. The job queue runs every 60 minutes. 2. All existing Opportunity Elements are processed. 3. For each Opportunity Element, it checks if items with this dimension combination still exist. 4. Opportunity Elements without associated items are deleted. **Example:** * Current: HP-Purchase, HP-Rent, Dell-Purchase, Dell-Rent * All Dell items are deleted or the dimension "Dell" is removed * Job runs - Opportunity Elements "Dell-Purchase" and "Dell-Rent" are deleted :::warning Important This job should **not run too frequently**, as it checks all Opportunity Elements and items. This can have performance impacts with large amounts of data. An hourly rhythm (60 minutes) is a good compromise between currency and performance. ::: ## Activate Job Queue Entries If the job queue entries are not yet active: 1. Open the job queue entry. 2. Set **Status** to **Ready**. ## Monitor Job Queue Entries ### Check Log Entries 1. Open the **Job Queue Entry**. 2. Click on **Job Queue** - **Log Entries**. 3. You see all previous executions with status: * **Success**: Successfully executed * **Error**: Failed, please check the error details ## Run Job Queue manually You can also run a job queue entry manually: 1. Open the job queue entry. 2. Click on **Process** - **Run Once (foreground)**. 3. The job queue entry is executed immediately. --- ## Opportunity Elements - Overview ## What are Opportunity Elements? Opportunity Elements are simplified product combinations formed from two dimensions of Items. They serve as a bridge between the detailed item master data in Business Central and a simplified product selection in Dynamics 365 Sales. **Example:** * Dimension 1: **Manufacturer** (HP, Dell, Microsoft, Lenovo) * Dimension 2: **Purchase Type** (Purchase, Rent, Leasing) **Result:** * HP-Purchase * HP-Rent * Dell-Purchase * Microsoft-Purchase * Microsoft-Rent * Lenovo-Purchase ## Why Opportunity Elements? ### Problem without Opportunity Elements Without Opportunity Elements, salespeople in Dynamics 365 Sales would have to choose from a large number of individual items. This leads to: * Lack of clarity * Errors in product selection * Time consumption during quote creation * Difficulties in forecasting ### Solution with Opportunity Elements With Opportunity Elements, sales in Dynamics 365 Sales works with only a few, clearly defined product combinations. The internal sales team in Business Central then enters the specific items in the sales quote. **Advantages:** * Simple product selection in Sales * Fast quote creation * Structured forecasts for controlling * Clear separation between sales (rough planning) and internal sales (detailed elaboration) ## The Business Process ```mermaid graph TD A["1. MASTER DATA (Business Central)Items with Dimensions → Generate Opportunity Elements"] -->|Synchronization to Sales| B["2. OPPORTUNITY (Dynamics 365 Sales)Salesperson selects Opportunity Elementsand enters estimated values (e.g. 'Microsoft-Rent: 50,000')"] B -->|Synchronization to BC| C["3. SALES QUOTE (Business Central)Internal sales creates detailed quote with specificItems, Quantities and PricesSystem automatically calculates totals per Opportunity Element"] C -->|Synchronization to Sales + PDF| D["4. UPDATE (Dynamics 365 Sales)Salesperson updates Opportunity with realvalues from the Quote (e.g. 'Microsoft-Rent: 25,500')Controlling uses precise forecasts"] ``` ## Practical Example: IT Distributor ### Initial Situation An IT distributor sells products from various manufacturers in different business models (purchase, rent, leasing). ### Setup * **Dimension 1 Code**: MANUFACTURER * **Dimension 2 Code**: PURCHASE TYPE * **Generated Opportunity Elements**: HP-Purchase, HP-Rent, Dell-Purchase, Microsoft-Purchase, Microsoft-Rent, Lenovo-Purchase, etc. ### Process **Step 1 - Opportunity in Sales:** Salesperson Hans creates an opportunity for customer "Example Ltd." and estimates: * Microsoft-Rent: 50,000 EUR * HP-Purchase: 10,000 EUR The salesperson can go into more detail in the description of the opportunity or in the description of the opportunity lines. For example, the description could state that it is likely 5 notebooks of the Elitebook series. **Step 2 - Sales Quote in Business Central:** Internal sales employee Maria creates a sales quote from the synchronized opportunity and enters: * 10 × Microsoft Surface Laptop (Dim: Microsoft-Rent) at 1,200 EUR = 12,000 EUR * 5 × Microsoft Surface Pro (Dim: Microsoft-Rent) at 1,500 EUR = 7,500 EUR * Microsoft 365 Subscription (Dim: Microsoft-Rent) at 500 EUR/Month × 12 Months = 6,000 EUR * 5 × HP EliteBook (Dim: HP-Purchase) at 1,400 EUR = 7,000 EUR As soon as the sales quote reaches a **Smart Workflow Tool** [process status](/docs/swt/setup.md#definition-of-a-process), the Sales Calculation Elements are calculated in the background. **Sales Calculation Elements (automatically calculated):** * Microsoft-Rent: **25,500 EUR** (instead of estimated 50,000 EUR) * HP-Purchase: **7,000 EUR** (instead of estimated 10,000 EUR) **Step 3 - Update in Sales:** Hans sees the quote in Sales and updates the opportunity with the real values (25,500 EUR + 7,000 EUR = 32,500 EUR instead of 60,000 EUR). **Result:** * Controlling has a **realistic forecast** based on concrete quotes. * Sales continues to work with simple product combinations. * Internal sales works with complete item details. --- ## Opportunity Elements - Setup This guide shows you how to set up Opportunity Elements in Business Central. ## Prerequisites Before you can set up Opportunity Elements, ensure that: * **Dimensions are created**: The two dimensions you want to use must already be created in Business Central (e.g., MANUFACTURER, PURCHASE TYPE, PRODUCT TYPE). * **Items are assigned Dimensions**: Items must have Default Dimensions. Only items with both configured dimensions and dimensions values are considered for Opportunity Elements. * **DYCE API Connector for Dataverse is installed**: The app must be installed and licensed. ## Step 1: Open Marketing Setup 1. Open Business Central. 2. Search for **Marketing Setup**. 3. Open the page. ## Step 2: Configure dimensions for Opportunity Elements Scroll down to the **Opportunity Elements** FastTab. ### Field: Opportunity Element Dimension 1 Code Select the first dimension to be used for the Opportunity Elements. **Examples:** * MANUFACTURER (e.g., for IT distributors) * INDUSTRY (e.g., for service providers) * ITEM CATEGORY (e.g., for wholesalers) **Important:** * This dimension forms the first part of the Opportunity Element Code. * The dimension must be defined as a Default Dimension on items. * Format of the Code: `Dim1Value-Dim2Value` (e.g., HP-PURCHASE). ### Field: Opportunity Element Dimension 2 Code Select the second dimension to be used for the Opportunity Elements. **Examples:** * PURCHASE TYPE (Purchase, Rent, Leasing) * PRODUCT TYPE (Notebook, Server, Desktop) * SERVICE TYPE (Consulting, Development, Support) **Important:** * This dimension forms the second part of the Opportunity Element Code. * The dimension must be defined as a Default Dimension on items. ### Field: Subscription Date Formula for Opp. Element Enter the Date Formula to be used for calculating subscription values. **Default Value:** `12M` (12 months) **What does this mean?** If a sales quote contains subscriptions, these are extrapolated in the Sales Calculation Elements. The formula determines the period for extrapolation. **Example:** * Subscription: Microsoft 365 at 50 EUR/month * Date Formula: 12M * Calculation: 12 × (50 EUR / 1 month) = 600 EUR * The value 600 EUR flows into the Sales Calculation Elements. :::info Note Use only simple Date Formulas with one period. Complex formulas like `2Y+6M` are not supported. ::: ## Step 3: Apply configuration and generate Opportunity Elements 1. When both dimension codes are configured, a confirmation prompt appears: ``` All existing Opportunity Elements will be deleted and recreated based on the new dimension configuration. Do you want to continue? ``` 2. Confirm with **Yes**. 3. The system automatically generates all Opportunity Elements based on the Item Dimensions. 4. A message indicates how many Opportunity Elements were created. ## Step 4: Check Opportunity Elements 1. Search for **Opportunity Elements**. 2. Open the list. 3. You see all generated Opportunity Elements with: * **Code**: Automatically generated (Format: Dim1Value-Dim2Value) * **Description**: Automatically generated from Dimension Value Names * **Dimension 1 Code** and **Dimension 1 Value** * **Dimension 2 Code** and **Dimension 2 Value** :::info Note Opportunity Elements cannot be created manually as they are automatically generated from Item Dimensions. The description can be changed manually. ::: ## Step 5: Set up Smart Workflow Tool process For Opportunity Elements to be automatically calculated for a quote, a corresponding [process](/docs/swt/setup.md#definition-of-a-process) must be set up in **DYCE Smart Workflow Tool**. 1. Search for **Processes** and open the list. 2. Create a new process for: * **Page**: `Sales Quote` * **Table**: `Sales Header` 3. Set a filter for the process: * **Document Type**: `Quote` 4. Define the desired process steps via the **Status** action (e.g., `NEW`, `IN PROGRESS`, `RELEASED`). 5. Select the status where the calculation should take place (e.g., `RELEASED`). 6. Click on the value in the **No. of Actions** column. 7. Add a new line: * **Type**: `Codeunit` * **Object ID**: `72077785` * **Description**: `DYCEACDOppElementWorkflowInt` This step ensures that when this status is reached, the Opportunity Elements are recalculated and updated based on the lines of the Quote. ## Important remarks ### Changing the dimension configuration If you want to change the dimension configuration: 1. **Check for active opportunities:** The system checks if open opportunities with Opportunity Calculation Elements exist. 2. **Error message with active opportunities:** ``` The dimension configuration cannot be changed because Opportunity Elements are used in active opportunities. ``` In this case, you must either: * Close the affected opportunities. * Remove the Opportunity Calculation Elements from the opportunities. 3. **Recreation of all Opportunity Elements:** Upon change, **all** existing Opportunity Elements are deleted and recreated. This also affects synchronization to Dynamics 365 Sales. ### Which items are considered? Only items that have **both** configured dimensions as Default Dimensions are considered for Opportunity Elements. **Example:** * Dimension 1: MANUFACTURER * Dimension 2: PURCHASE TYPE * Item "Surface Laptop": * Default Dimension MANUFACTURER = Microsoft * Default Dimension PURCHASE TYPE = Rent * The Opportunity Element "Microsoft-Rent" is created. **Items without complete dimensions are ignored:** * Item "USB Cable": * Default Dimension MANUFACTURER = Miscellaneous * No Default Dimension PURCHASE TYPE * No Opportunity Element is created. ### How many Opportunity Elements are created? The number results from the **actually occurring combinations** in the item master data. **Example:** * 4 Manufacturers: HP, Dell, Microsoft, Lenovo * 3 Purchase Types: Purchase, Rent, Leasing * **Theoretical Maximum**: 4 × 3 = 12 Opportunity Elements **However:** If, for example, no item has the combination "Lenovo-Leasing", this Opportunity Element is not created. ## Troubleshooting ### "No Opportunity Elements are created" **Possible Causes:** * No items have both dimensions as Default Dimensions. * The dimension codes are configured incorrectly. * Items are not assigned the correct dimension values. * The Job Queue for generating Opportunity Elements is not configured or not running. **Solution:** 1. Check the Default Dimensions on your items. 2. Ensure that items have both dimensions. 3. Check the Job Queue entries. --- ## Working with sales opportunity elements # Working with Sales Opportunities This guide shows you how to work with synchronized opportunities from Dynamics 365 Sales in Business Central and create quotes. ## Prerequisites * Opportunity Elements are set up in Business Central. * Opportunities have been created in Dynamics 365 Sales and synchronized to Business Central. * **[DYCE Smart Workflow Tool](/docs/swt/welcome.md)** is set up (for the synchronization of sales quotes back to Sales). ## Overview: The work process ```mermaid graph TD A["DYNAMICS 365 SALES- Sales employee creates sales opportunity- Selects sales opportunity elements (e.g. 'Microsoft rent')- Captures estimated values (e.g. EUR 50,000)"] -->|Synchronization| B["BUSINESS CENTRAL1. Open opportunity2. Create sales quote from opportunity3. Enter specific items, quantities and prices4. Set process status via DYCE Smart Workflow5. System automatically calculates sales elements"] B -->|Synchronization| C["DYNAMICS 365 SALES- Sales employee sees Sales Quote- Can update sales opportunity with real values"] ``` ## Step 1: Open synchronized opportunity ### Find opportunity 1. Search for **Opportunities** in Business Central. 2. Open the opportunity list. 3. You can recognize synchronized opportunities from Sales: * Field **Dataverse ID** is filled. * Field **Dynamics Sales Link** contains a link to the opportunity in Sales. ### Open opportunity 1. Select the desired opportunity. 2. Open the opportunity card. ### Check opportunity lines In the **Opportunity Lines** fast tab, you will see the estimated values from Dynamics 365 Sales: * **Opportunity element code**: e.g. "Microsoft Rent" * **Amount (MW)**: Estimated amount without VAT. * **Amount incl. VAT (MW)**: Estimated amount incl. VAT. * **Contribution margin (MW)**: Estimated contribution margin (if recorded by sales) **Example:** | Code | Amount (MW) | Amount incl. VAT (MW) | |---|---|---| | Microsoft rental | 50,000.00 | 59,500.00 | | HP purchase | 10,000.00 | 11,900.00 | ## Step 2: Create Sales Quote from opportunity ### Create Sales quote via standard function 1. Click on **Start** in the open opportunity card. 2. Select **Create Sales Quote**. 3. A new sales quote is created and opened. 4. The Customer and basic information are automatically transferred. :::info Note on the opportunity The opportunity itself is **read-only** as it was synchronized from Sales. They can only be changed via synchronization in Sales. However, the sales quote in Business Central is fully editable. ::: ## Step 3: Fill the sales quote with specific items Now enter the actual items, quantities and prices in the sales quote. ### Enter items Enter the sales lines as usual: 1. **Type**: Item 2. **Number**: Select the specific item 3. **Quantity**: Enter the desired quantity 4. **Unit price**: Is filled automatically, can be adjusted **Important for sales calculation elements:** The items must have the configured dimensions as standard dimensions so that they are included in the calculation for sales elements. If subscriptions are used, the corresponding subscription lines are also taken into account in the calculation. ## Step 4: Set process status (DYCE Smart Workflow Tool) You must set a defined process status so that the quote is synchronized to Dynamics 365 Sales and the values are calculated automatically. ### Prerequisite: DYCE Smart Workflow Tool configured The administrator (or a power user) must have configured a [process](/docs/swt/setup.md#definition-of-a-process) incl. process status in **DYCE Smart Workflow Tool** that: 1. Triggers the calculation of the sales calculation elements. 2. Starts the synchronization to Dynamics 365 Sales. **Typical process status:** "Released for synchronization" or "Checked" ### Set process status 1. Open the **Sales Quote**. 2. Search for the **Process Code** and **Process Status Code** field. 3. Select the process. 4. Select the process status. 5. Save the sales quote. ### What happens now? The quote is synchronized to Dynamics 365 Sales and the calculated values are transferred. The sales employee sees the quote in Sales and can, for example, update the opportunity if the values differ. ## Step 6: What happens in Dynamics 365 Sales? ### Quote available in Sales In Dynamics 365 Sales, the sales employee sees the synchronized quote with lines containing the corresponding opportunity elements with the *actual, calculated values*. ## Frequent scenarios ### Scenario 1: Item has incorrect or missing dimensions **Problem:** An item is recorded in the sales quote, but it is not included in the calculation. **Cause:** The item does not have both configured dimensions as standard dimensions. **Solution:** 1. Open the Item card. 2. Navigate to **Dimensions** - **Default dimensions**. 3. Make sure that both dimensions are configured: * Dimension 1 (e.g. MANUFACTURER) * Dimension 2 (e.g. PURCHASE TYPE) 4. Reopen the sales quote and add the item again. 5. Set the process status again. ### Scenario 2: Sales quote is not synchronized to Sales **Problem:** The Sales quote does not appear in Dynamics 365 Sales, although the process status has been set. **Possible causes:** * The process status is not configured for synchronization. * The opportunity is not linked to Dynamics 365 Sales. * Synchronization error **Solution:** 1. Check if the opportunity has a **Dataverse ID**. 2. Check the **DYCE Smart Workflow Tool** configuration. --- ## Jobs [DataBridge](/docs/acd/administration/setup-integration.md#DataBridge) manages various synchronization jobs that automatically maintain data consistency between Business Central and Dynamics 365 Sales. Each job handles specific data types and follows predefined mapping rules configured during the initial setup. A job is a definition of what should be done, specifying the source and destination of data, along with a given order and schedule. It always uses a mapping, which is defined separately, as different jobs could use the same mapping. Key aspects of a job: * **Order:** Defines the sequence in which jobs are executed. * **Direction:** Specifies the data flow direction (e.g., Business Central to Dynamics 365 Sales). * **Trigger:** Determines when and how the job is initiated, including the schedule, source and target connections, watermark type, watermark field, and filters. * **Mapping:** Specifies the data transformation rules between source and destination. * **Relationships:** Describes how the synchronized data relates to other entities. ## Standard Job Information The DataBridge documentation describes a standard set of jobs that covers the most common integration scenarios. These jobs are configured and managed through the DataBridge interface. :::tip DataBridge standard jobs For detailed information about standard jobs, their schedules, and configuration options, please see the DataBridge documentation: **[DataBridge Jobs Documentation](https://salescentral.docs.dsyr.de/databridge/jobs/000%20-%20abstract.html)** ::: This external documentation maintained by wysa provides: * Complete list of available synchronization jobs * Job scheduling and frequency options * Monitoring and troubleshooting guidance * Custom job configuration possibilities ## Job Customization If your organization requires additional synchronization jobs beyond the standard offering, please contact **Singhammer**'s project team for: * Custom job development and configuration * Modified synchronization schedules * Additional data entity synchronization * Integration testing and validation If you are a partner and require customization, please reach out to **Singhammer**'s product team. --- ## Mappings [DataBridge](/docs/acd/administration/setup-integration.md#DataBridge) uses mappings to define how data flows between Business Central and Dynamics 365 Sales. A mapping specifies the correspondence between source fields and target fields, ensuring data consistency and proper transformation during synchronization. Mappings consist of several key elements: * **Key Resolution:** Determines how records are matched between systems, often using custom keys or unique identifiers (e.g., searching for a Business Central System Id in the target system). * **Source Definition:** Specifies the source table or API and its attributes in Business Central. * **Target Definition:** Specifies the target table or entity and its attributes in Dynamics 365 Sales. * **Field Transformation:** Defines how each source field is mapped to a target field, including technical names and display names, and may include transformation logic or formatting. Mappings are configured to ensure that data is correctly identified, transferred, and transformed between systems, supporting both standard and custom business requirements. ## Standard Mapping Configuration wysa provides a comprehensive set of standard mappings during the initial implementation that covers the most common data synchronization scenarios. These mappings are carefully designed to maintain data integrity and business logic across both systems. :::tip DataBridge field mappings and configuration For detailed information about current field mappings and their configuration, please refer to the DataBridge documentation: **[DataBridge Mappings Documentation](https://salescentral.docs.dsyr.de/databridge/mappings/000%20-%20abstract.html)** ::: This external documentation maintained by wysa provides: * Complete overview of all standard field mappings * Data transformation rules and logic * Custom mapping configuration options * Field mapping troubleshooting guidance ## Custom Mapping Requirements If your organization requires custom field mappings beyond the standard offering, please contact **Singhammer**'s project team for: * Custom mapping development and configuration * Additional field synchronization requirements * Data transformation customizations * Mapping validation and testing If you are a partner and require customization, please reach out to **Singhammer**'s product team. --- ## Synchronization # General [DataBridge](/docs/acd/administration/setup-integration.md#DataBridge) enables automated synchronization between Business Central and Dynamics 365 Sales using scheduled jobs and defined mappings. These jobs ensure data consistency by reading records from the source system and writing them to corresponding records in the target system according to mapping rules. Synchronization jobs are configured with specific schedule and order options, determining how frequently and in what sequence data is synchronized. Standard job schedules and configuration details are described in the wysa documentation. ## Data Flow Overview **DYCE API Connector for Dataverse** enables bi-directional synchronization between Business Central and Microsoft Dynamics 365 Sales (Dataverse) through a series of automated jobs managed by DataBridge: * **From Business Central to Dynamics 365 Sales** * Countries, Languages, Salutations * Customer Discount Groups, Salespersons * Positions, Manufacturers * Contacts (Company, Person) * **From Dynamics 365 Sales to Business Central** * New Accounts (Company Contacts) and Contacts (Person Contacts) * New and updated Opportunities * Account (Company Contact) and Contact (Person Contact) updates ## Synchronization Jobs DataBridge manages various synchronization jobs that run automatically to keep data consistent between systems. Each job handles specific data types and follows predefined mapping rules. :::info Detailed job configuration, including scheduling and order, is handled through the DataBridge interface. Standard job schedules and options are documented in the [wysa DataBridge Jobs Documentation](https://salescentral.docs.dsyr.de/databridge/jobs/000%20-%20abstract.html). ::: ## Custom Data Synchronization If your organization requires synchronization of additional data entities beyond the standard offering, please contact **Singhammer**'s project team for implementation and testing of: * **Custom API Pages** can be created in Business Central to expose additional data * **Custom Mappings** can be configured in DataBridge to handle the new data flows If you are a partner and require customization, please reach out to **Singhammer**'s product team. --- ## User Experience While **DYCE API Connector for Dataverse** operates primarily as a background synchronization service, users will notice integration enhancements in several areas of Business Central. ## Contact Card Enhancements When viewing contact records in Business Central, users will directly see the **Dataverse ID** field, which displays the corresponding record ID in Dynamics 365 Sales. This provides immediate visibility into the connection between Business Central contacts and their Sales counterparts. ## Opportunity Card Enhancements The Opportunity card includes new fields that help inside sales teams identify opportunities more efficiently: * **Dataverse ID** - The record ID of the corresponding opportunity in Dynamics 365 Sales * **Dataverse Opportunity No.** - Shows the Sales system's opportunity number * **Dynamics 365 Sales Information FastTab** with key details from Dynamics 365 Sales: * **Expected Closing Date** - Projected close date from Sales * **Expected Revenue** - Revenue forecast from Sales * **Dynamics Sales Link** - Direct hyperlink to open the opportunity in Dynamics 365 Sales These enhancements provide Business Central users with immediate visibility into sales activities and enable quick navigation between systems. When an opportunity is created by Sales, it will automatically be activated in Business Central. Therefore, it is important to have a default **Sales Cycle Code** defined in your Business Central setup. To set up sales cycle codes, follow the official Microsoft documentation: **Set Up Opportunity Sales Cycles and Stages**. Sales Cycle Codes help structure your opportunity management and ensure new opportunities are activated correctly. ## Dataverse Integration Log Entries **DYCE API Connector for Dataverse** logs integration-relevant events for synchronization with Dataverse. This includes deletions and certain transfers for the following tables: * Contact * Country/Region * Customer Discount Group * Customer Price Group * Language * Manufacturer * Organizational Level * Salesperson/Purchaser * Salutation * Sales Header * Sales Line Additionally, transfers from sales quotes to orders are logged. Entries are created automatically when records are deleted or transferred, enabling DataBridge to process these changes in Dynamics 365 Sales. Processed entries are marked by DataBridge, and a retention policy is created when DYCE API Connector for Dataverse is installed. ## Retention Policy By default, DYCE creates retention policies for integration log entries: * **Processed entries** are deleted after **1 month** * **Unprocessed entries** are deleted after **6 months** You can customize retention policies as needed. For more information, refer to the official documentation: [Data Retention Policies in Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/admin-data-retention-policies). --- ## Individual Setup # User menu Individual settings for each user are opened via the user menu. It is located at the level of the heading, to the right above the respective workspace. The settings in this area only affect the user who made them. The menu shows information such as name, email and the Business Central instance for the logged-in user. The user can explicitly *log out* here, *[switch companies](#switch-companies)* and enter the user *[settings](#settings)*. ## Switch companies To change the company, the user must be created in the other company. Time recordings, templates and the users themselves are company-specific. Therefore, time recordings and templates from one company are not visible in other companies. ## Settings The user settings are divided into a [General](#general) part and a part specifically for [Time Tracking](#time-tracking). ### General Settings on the **General** page control how the entire app is displayed to the user. * ****Language and region** The **Language** and **Region** is taken from the browser when the user first logs in. Each user can change the language and region in the **Settings**. The region effects the date and time format. English and German languages are available. If a language other than German is stored in the browser, English will be defaulted to. Some browsers allow setting a language but no region. In Chrome, for example, German or German/Germany can be selected in the languages settings. If no region is stored or cannot be recognized, United States will be selected automatically. * **Dark mode** If the Dark Mode is activated, the complete app is displayed in eye-friendly colors. Dark Mode can be activated and deactivated via the **Mode** toggle. * **Consent to the use of user data and data traffic** In order to provide optimal support and to continuously improve **DYCE Connect**, we record user data and data traffic. Consent can be given via the cookie banner and in the setup. If no consent is given, no data is recorded. No errors either. ### Time tracking Settings in the **Time Tracking** page only affect the display of the *Time Tracking* area. * **Selection of Time Tracking form** Different time recording masks can be selected to use for creating time recordings. All masks work basically in the same way, they only differ regarding the fields displayed. The following time recording masks can be selected: * **All** In this mask all fields are displayed. This time recording mask is used as default when the time recording is opened for the first time. * **Compact** In this mask the fields *Start*, *End* and *Break* are not displayed. * **Simple** In this mask the fields *Start*, *End*, *Break* and *Customer* are not displayed. * **Dynamic** This mask is one of the masks used in Azure DevOps. All fields are displayed in this mask. The preview below the selection shows the selected mask. Changing the Time Tracking Form changes the display on the **Recordings**, **Incomplete** and **Templates** page. * **Export** Time Recordings are automatically synchronized in Business Central. Time Recordings can also be exported using the **Export** function. Only the time recordings of the user performing the export are exported. The exported Time Recordings are provided as JSON. * **Show days without capacity** The **Show days without capacity** button controls which days are displayed in time recordings and the dashboard. Depending on the setting, all days or only working days are displayed. By default, only working days are preset according to the working time model and base calendar. * **Calendar settings** Before you can see your Outlook calendar entries, you must grant read permission once. The read permission can be revoked at https://myapps.microsoft.com/. Find the DYCE app, click on the three dots, select *Manage your application* and then *Revoke Access*. ## Miscellaneous * **Task Grouping** The grouping of tasks is defined here. Each user can choose between grouping by **Customer**, **Project** (default), **Start date** and **End date**. * **URL** Information on the app, page, environment, company and tag can be encoded in the URL. |Component|Example URL|Comment| |---|---|---| |Base URL|https://app.dyce.cloud/|Opens the *selection* of apps. If the user only has access to one app, they are automatically redirected to this app.| |App|https://app.dyce.cloud/timetracking|Opens the *Time Tracking* app in the last used environment and company.| |Page|https://app.dyce.cloud/timetracking/dailyrecordings|Opens the page *Time Recordings* (*dailyrecordings*) on the current day and last used environment and company.| |Dailyrecordings|https://app.dyce.cloud/timetracking/dailyrecordings#2024-04-12|Opens the *Time Recordings on 12.04.2024*. The filter *#2024-04-12* only works on the page Time Recordings.| |Environment|https://app.dyce.cloud/timetracking/dailyrecordings?instance=demo#2024-04-12|Opens Time Recordings on 12.04.2024 in the *Demo* environment (*?instance=demo*).| |Company|https://app.dyce.cloud/timetracking/dailyrecordings?instance=demo&company=Intern#2024-04-12|Opens the Time Recordings on 12.04.2024 in the company *Intern* (*?instance=demo&company=intern*).| |Tenant|https://app.dyce.cloud/?tenant=customer.onmicrosoft.com|Signs a B2B guest user in against a specific tenant. See [Guest login for external tenants](/docs/web/administration/setup-web.md#guest-login).| `instance` and `company` select the environment and company the app opens in. Specify both to open a specific workspace. Either may be left out when it is unambiguous: `company` alone is enough when the user has access to only one environment, and `instance` alone is enough when that environment contains only one company. If the environment or company still cannot be resolved, or the user has no access to it, the app falls back to its usual behavior: the last used environment and company, otherwise the selection screen, or the only available one when there is just one. Special characters that represent invalid characters in a URL must be encoded. For example, *blanks* must be replaced by *%20*. ## Pre-fill a new time recording via URL {#prefill-time-recording} An external system, for example a ticket tool, can open **DYCE Time Tracking** on a new time recording that is already pre-filled with the data known in the source system. The user only completes the remaining fields and saves, which keeps manual data entry to a minimum. To request a pre-filled form, open the **Time Recordings** page with `newRecord=true` and at least one of the parameters below, for example: `https://app.dyce.cloud/timetracking/dailyrecordings?newRecord=true&jobId=&duration=60&description=Kickoff%20call` `newRecord=true` on its own opens the normal empty new-record form. |Parameter|Description| |---|---| |`newRecord=true`|Requests the pre-filled form. Must be set to `true`, together with at least one of the parameters below.| |`instance`|Business Central environment (as in the [URL](#miscellaneous) table above).| |`company`|Company within the environment.| |`date`|Date of the time recording as an ISO date (*YYYY-MM-DD*). Takes precedence over a `#YYYY-MM-DD` hash. Can be omitted when `start` (or `end`) already includes the date.| |`start`|Start time as a full ISO date and time.| |`end`|End time as a full ISO date and time.| |`duration`|Duration in minutes.| |`durationBillable`|Billable duration in minutes.| |`break`|Break in minutes.| |`description`|Free-text description.| |`customerId`|Customer id.| |`jobId`|Project id.| |`jobTaskId`|Project Task id.| |`jobPlanningLineId`|Project Planning Line id.| |`tntModelLineId`|Time & Travel Model Line id; the matching activity is selected accordingly.| |`workOrderId`|Work Order id; its customer and project are taken over into the time recording.| |`nonBillableReason`|Non-billable reason. Applied only when it matches a valid value.| Each id is the record's **System Id** (a GUID), the same identifier the record has in Business Central. If the parameters contradict each other (for example a customer and a project that do not belong together), the higher-level field wins and the lower-level field is left blank. As above, special characters must be URL-encoded, for example a blank as *%20*. ### Start and end times {#prefill-start-end} `start` and `end` are [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) date and time values and can be passed in two ways: * **Without a time-zone offset** (simplest): the time is interpreted in the user's local time zone, for example `start=2026-09-22T14:00:00`. * **With an explicit offset:** the `+` must be encoded as *%2B*, otherwise it is read as a space and the offset is lost, for example `start=2026-09-22T14:00:00%2B02:00` for UTC+02:00. --- ## Permissions(Administration) Since users do not create their Time Recordings in Business Central, various tasks require additional permissions outside of Business Central, accordingly. ## Permissions in Business Central The permission set **D365 BASIC** has been expanded by all permissions, which are necessary for the synchronization of Time Recordings from **DYCE Time Tracking** with Business Central. ## Create new companies Users who [create new environments and companies](/docs/web/administration/setup-sync.md) in **DYCE Connect** must be assigned the **Application administrator** role in their *Microsoft Entra ID* account. ## Roles and permissions In **DYCE Connect** permissions are assigned by using roles. Depending on the [role](/docs/web/administration/setup-web.md) different areas are shown or hidden. --- ## Business Central(Administration) # Setup in Business Central The best user experience and highest degree of automatization can only be archived by completing the necessary setup for the **DYCE Connect Platform** app. Some of these setups will need to be done in Business Central / **DYCE Project Billing** respectively. ## Allowing HTTP requests for DYCE Sync In order for the synchronization to work, it needs to be able to communicate with the backend of the **DYCE Connect** platform. If you are creating a new Time Tracking environment for the first time, the app will ask to *allowing HttpClient requests*. If you have denied that request, follow the steps below to check or re-enable this option: 1. Go to the Extension Management page by typing *extension* in the search (*Alt+Q*). 2. Search for **DYCE Sync** by **Singhammer IT Consulting AG** and click on *View* action (either via the three dots or via action group *Manage*). 3. Allow HttpClient requests. ## Resources To make life easy for the Time Tracking users, some setups must be made in Business Central. Separate resources should be created for all time trackers and the employees to be planned. At the same time, it is recommended that a **calendar** and a **working time template** be set for these resources. In order to do so, navigate to the resource and open the **Resource Person Defaults** page (in *Resource* menu group,). In the **Base Calendar**, holidays and other non-working days are maintained. In the **Work-Hour Template**, the different working time models are maintained. In each working time model, it is possible to specify which days of the week should be a workday including the quantity of working hours to be fulfilled. In **DYCE Time Tracking**, only these days are displayed to the user for time recording by default. :::info Work-Hour Template If no Work-Hour Template is defined for a resource, Time Tracking assumes seven days per week with eight hours per day (7x8). ::: :::tip 1. To display *all* days, despite **Work-Hour Template** or holidays, use the option **Show days without capacities** in the setup. 2. Regardless of whether a day is displayed or not, a time recording can be captured for every day. Changing the date in a time recording will move it to the appropriate day. ::: ## Time & Travel Model **[Time & Travel Models](/docs/pb/setup/tnt-model.md)** offer several powerful features that greatly simplify the work of everybody involved. The activity in the time recording is used, among other things, to control the billing, the rounding of the billable duration and the selection of the Project Planning Line. Capture and release of time recordings is thus significantly accelerated and facilitated. The activity can only be selected if the Time & Travel model is set up and stored in the [Project Card](/docs/pb/masterdata/project.md#structure-of-the-project-card) in **DYCE Project Billing**. ## Permissions This section deals with the permission sets supplied. To review the permissions included in the permission sets in detail, please open the **Permission Sets** page (*Alt+Q*) and then call the **Permissions** action. It is not necessary to explicitly configure permissions in order to use the app. Nevertheless, the following permission sets are included with the app: * **DYCE SYNC TRACKING (DYCE Sync Tracking)** This permission set contains the **DYCE Tracking Table** table and is intended for troubleshooting for synchronization with **DYCE Connect** (***DYCE SYNC***). The same permissions extend the standard permission set D365 BASIC (Dynamics 365 Basic access). * **DYCE SYNC ADMIN (DYCE Sync Admin)** This permission set contains full access to all tables for synchronization with **DYCE Connect** (***DYCE SYNC***) and also deletion rights to the **DYCE Tracking Table** table. The same permissions extend the standard permission set D365 SETUP (Dyn. 365 Company data setup). For more information about permission sets, see this part of the Microsoft documentation. --- ## Companies and Synchronization # Create companies and set up synchronization **DYCE Time Tracking** and **DYCE Project & Resource Planning** use companies and environments. For each company in Business Central, a company can be created in the **DYCE Connect Platform**. The users can freely switch between the companies as long as they are set up in the chosen company. ## Create new companies New companies for **DYCE Connect** are created from Business Central. One company in **DYCE Connect** corresponds to one company in Business Central. To create a new company and connect it to one in Business Central, the **DYCE Synchronization Setup Wizard** must be called from Business Central. The wizard performs the *onboarding* and hereby all necessary steps and prepares the company in **DYCE Connect**. It can be accessed via the **DYCE Setup Synchronization** page or by the search (*Alt+Q*). In this process, the *Enterprise application* **DYCE** (with the application ID *5ac2d7d3-ff4d-4a8a-a1ff-204580a4696e*) is added in *Microsoft Entra*. The user who will be running the wizard will need to have the appropriate permissions and roles. Specifically, they will need a Business Central license, sufficient user permissions, and the **Application Administrator** role (in *Microsoft Entra*). :::note User in DYCE Connect The user who created the new environment in **DYCE Connect** is automatically set up as a user. Additional users must then be added manually and assigned the appropriate roles. ::: Once the wizard has been run and the **DYCE Connect** environment is ready, two things should be done. First, synchronization should be turned on (set **Automatic Synchronisation enabled** to *YES*) and the corresponding entries in the job queue should be checked. It must be verified that the status of the *DYCE Sync Task* (70921505) and *DYCE Task Watchdog* (70921489) entries is set to *Ready*. Please check the **Earliest Start Date/Time**, as well. Second, a **Full Sync** is always to be carried out to synchronize the existing data from Business Central to **DYCE Connect**. The continuous synchronization process will start shortly after the creation of the company is finished. :::tip Perform full sync A **Full Sync** can either be initiated manually in the **DYCE Synchronization Setup** page or at the end of the onboarding wizard. ::: ## Full Sync {#full-sync} A **Full Sync** sends every synchronized record from Business Central to **DYCE Connect** and reconciles the two systems, so that **DYCE Connect** reflects the current state of Business Central. It runs at the end of the onboarding wizard and can be started again at any time from the **DYCE Synchronization Setup** page, for example when the data differs between the two systems. During a Full Sync, Business Central re-sends every synchronized record. **DYCE Connect** matches these against its own data and reconciles the two systems: records that still exist in Business Central are updated, records that Business Central no longer has (for example a project, resource or customer that was deleted there) are removed from **DYCE Connect**, and data that both systems maintain (such as time recordings and work orders) is kept and re-sent to Business Central. In practice, a Full Sync cleans up and re-sends the following data: * **Updated in DYCE Connect, or removed when no longer present in Business Central:** projects, project tasks and project planning lines, resources, customers, calendars, skills, and Time & Travel models. * **Re-sent to Business Central:** time recordings, work orders (with their lines, events and statuses), absences, billing dispositions, and supporting lists such as areas, locations, sprints and sub-types. :::note Work can continue during a Full Sync In general, users may keep booking time recordings and creating work orders while a Full Sync is running, and records created or changed during the run are preserved. Because a Full Sync also reconciles master data that no longer exists in Business Central, it is best run during periods of low activity: an entry created against data that is being removed in the same run (for example a project, resource or customer deleted in Business Central) may afterwards be incomplete and need to be reviewed. ::: ## Synchronization setup In the **DYCE Synchronization Setup** page in Business Central, the synchronization setup can be edited and a **Full Sync** can be triggered. In the page, the interval between sessions and the number of queries per session can be edited. If **Sync Task enabled** is changed to *NO*, the execution of the synchronization via the Job Queue (codeunit 70921505) will also be stopped. :::info DYCE Sync Tasks in the Job Queue If **automatic synchronization** is enabled, the synchronization is executed in the background via the Job Queue. Three job queue entries are relevant for the synchronization: 1. **DYCE Sync Task** (Codeunit 70921505): This task is responsible for sending and receiving data from **DYCE Connect**. It restarts itself and runs continuously, waiting for new messages to process. 2. **DYCE Task Watchdog** (Codeunit 70921489): The watchdog checks whether the synchronization task is running and reactivates it if this is not the case. 3. **DYCE Purge Log** (Codeunit 70921482): This task cleans up the processed incoming and outgoing messages that are older than 30 days. Unprocessed messages or messages that are in error state are not deleted. ::: In the **Unprocessed outgoing Messages** field, it is possible to see how much data has *not* yet been sent to **DYCE Connect**. As soon as a record is created in Business Central, it is displayed in this field until it has been sent. If the synchronization is complete, the data will be marked as processed successfully and not be shown anymore. :::tip The state that data is not sent at all should not occur. It is an indication that synchronization is not enabled or a problem has occurred in the Job Queue. ::: In the **Unprocessed incoming Messages** field, you can see how much data was received from **DYCE Connect** which could not be processed correctly. Clicking on the number will open the affected records. Unprocessed messages can be corrected and processed again. :::warning Sequential Processing If received data is reprocessed, the order in which the record was updated must be kept. If the records are processed in a different order than they were received the content of the data may be changed. The **Time Stamp** can be used to determine the order, in which the messages where received. The *Create* operation must be carried out before an *Update*. *Delete* should always be the last operation to be performed. If the data differs between **DYCE Connect** and Business Central, the **Full Sync** action can be used to synchronize the data. ::: A complete list of log entries can be accessed in the **Logs** menu group. In the *Statistics* info tab you can see when the last heartbeat was sent and received. :::info Unprocessed Records In the [administration area](/docs/web/administration/setup-web.md#synchronisation), the unprocessed records of the **DYCE Connect Platform** and Business Central can be viewed and edited. ::: :::warning Warning There is more than one way to *accidentally* interrupt synchronization. These must be avoided. * Creating, deleting or modifying data with configuration packages Non-validated data is potentially not synchronized, because it skips all validation logic. The **DYCE Connect Platform** uses the **System Id** as a reference between records. The System Id is not imported in Business Central, but is newly created. E.g. Importing time recording with the Time & Travel Model line Id will fail, if the Ids do not match the ones in the Time & Travel Model. * Delete a Business Central Company (with a **DYCE Connect** environment), create a new one with the same name and run the Onboarding wizard. The new Business Central Company will reconnect to the existing **DYCE Connect** environment. * **Retry** processing **Not processed Messages** in the wrong order For example, if a Time Recordings is changed twice in Time Tracking and not processed automatically in Business Central, the user can trigger the processing again. If the second update is processed by the user before the first, the Time Recordings will be overwritten with an old state. ::: --- ## General Setup(Administration) # Setting up DYCE Connect The **DYCE Connect Platform** provides the features [Time Tracking](/docs/web/tt/welcome.md) and [Project & Resource Planning](/docs/web/prp/welcome.md). Both areas also have their own setups (see [Time Tracking](/docs/web/tt/setup/setup.md) and [Project & Resource Planning](/docs/web/prp/setup/setup.md)). ## Synchronization status {#synchronisation} The **Synchronization** page shows the status of the synchronization and the related company in Business Central. The traffic light shows the status at a glance. * **Green** means that everything is working as desired. * **Blue** is displayed if a heartbeat has been missed. * If the traffic light is **yellow**, there is at least one data record that could not be processed. * If the traffic light shows **red**, synchronization cannot be achieved. Unprocessed and unsent data can be opened directly. The creation of companies and the setup of synchronization are explained in detail in [this section](/docs/web/administration/setup-sync.md#synchronization-setup) of the documentation. ## Feature Management {#feature-management} Administrators can enable or disable Time Tracking and Project & Resource Planning on the **Feature Management** page in the **Administration** area. The selected features directly influence the available application areas and the billing. They act as a master switch that controls both user access and usage-based charges. When a feature is disabled, no billing occurs for that feature, and users cannot access the corresponding functionality. Each feature displays current usage details: * **Time Tracking**: Number of users with [time recording permissions](#time-recording) * **Project & Resource Planning**: Number of plannable [resources](/docs/pb/masterdata/resource.md) ### Enabling a Feature To enable a feature, toggle the switch to *On*. A confirmation dialog will appear: * Users with appropriate roles will gain access to the functionality * Usage-based billing will apply * The [terms of use](/docs/general/terms-conditions.md) must be accepted :::tip * Features can be tested without charges in sandbox environments. * After enabling a feature, users still need to be [assigned the corresponding roles](#roles-and-permissions) to grant them access to the new functionality. ::: ### Disabling a Feature When disabling a feature: * All users immediately lose access to the functionality * User permissions for the feature are removed * Existing data is preserved but cannot be modified while disabled * Work orders remain editable if either Time Tracking or Project & Resource Planning is enabled :::warning 24-Hour Waiting Period Features can only be disabled after 24 hours have passed since they were last enabled. If disabling is attempted earlier, a message indicates when it becomes available. ::: ## Setup valid for all users These settings apply to all users in the company. Based on the settings, additional fields are displayed to all users in lookups or the selection in lookups is limited. The setup can be accessed in the **Settings** page in the **Administration** area. ### Work Orders #### Enable Work Orders Determines whether work orders are enabled in the application. With this toggle, [Work Orders](/docs/pb/professional-services/work-order.md) can be activated and deactivated in the entire application. If work orders are not used, this switch should be deactivated in order to keep the user interface as clear as possible. #### Enable Exchange Online Integration {#exchange} Show events from Exchange Online in the work order [planning calendar](/docs/web/prp/planning/calendar.md). To avoid conflicts in resource planning, the planning calendar of **DYCE Project & Resource Planning** can display appointments from the Exchange online calendars of users. This allows planners to take into account existing appointments when scheduling work orders. To allow **DYCE Connect** read access to users' Exchange online calendars, the *Microsoft Entra administrator* must first grant the necessary permissions by clicking on *Allow read access*. This will open the Microsoft Entra consent dialog and request the additional application permission [Calendars.Read](https://learn.microsoft.com/en-us/graph/permissions-reference#calendarsread). :::note Restricting access to individual mailboxes The mailboxes that are accessible to **DYCE Connect** can be controlled by the administrator. [Role Based Access Control for Applications in Exchange Online](https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac) provides more information on this topic. ::: After enabling the integration and giving consent, a basic test can be performed by clicking on the *Test integration* button. If the test is successful, a green checkmark and a message similar to "Successfully tested on 17. Sept. 2025, 13:00 CEST" will be displayed. If the test fails, a red cross and an error message will be displayed. :::important Privacy note We treat appointments as sensitive information. **DYCE Connect** therefore does not store any appointment data permanently. The appointments are only retrieved from Exchange online and displayed in the planning calendar while users are working with the calendar. We request appointments for the displayed resources only. Appointments marked as private are displayed as such. ::: ### Tasks The **Assigned Tasks** field offers three options: *None*, *Optional*, and *Mandatory*. * **None** The **Tasks** page will not be displayed in the sidebar. The user cannot filter by assigned tasks in the time recording lookups. * **Optional** The **Tasks** are displayed in the sidebar. In the time recording lookups, it is possible to filter by assigned tasks. The filter can be activated and deactivated using the *Tasks icon* in the time recording lookup. This allows the users to limit their selection in the time recording and optionally select from the entire list. * **Mandatory** All lookups in the time recording will be filtered to the assigned tasks. The filter cannot be deselected. This ensures that the users can only create time recordings for tasks that have been assigned to them. The **Tasks** are displayed in the sidebar. ### Project tasks The **Project Task No.** toggle specifies whether the Project Task numbers are displayed in the lookup. By default, **Project Task No.** is deactivated. If a project is entered in the time tracking mask, the entries in the Project Task lookup are sorted by the description of the Project Tasks. If no project is entered, the entries in the Project Task lookup are sorted by Project No. and description. If **Project Task No.** is activated, the display and sorting in the Project Task lookup changes. The Project Task No. is displayed in the first position in the lookup. The entries in the Project Task lookup are sorted by Project Task number. The number is not a *number* but a so-called code field in Business Central. In addition to numbers, letters and special characters can be entered in the field. Accordingly, a Project Task with the number *1000* is shown above a Project Task with the number *200*. Project Tasks with a letter at the beginning are always placed at the end. ### Time recordings The **Activity expected** toggle controls whether Time Recordings without activities are flagged as *incomplete*. For a Time Recording to be considered *complete*, all mandatory fields must be filled in. By default, **Activity** is not a mandatory field. If **Activity expected** is activated, *new* Time Recordings without **Activity** are displayed as *incomplete*. Time Recordings without activity can still be released in Business Central. When an incomplete Time Recording is released in Business Central, it is marked as *complete*, regardless of whether the **Activity** is filled or not. :::warning Important The change is only applied to newly created Time Recordings. The change of **Activity expected** is not applied to existing Time Recordings. ::: ### Attendances **Display Attendances** Determines whether the page **Attendance** is displayed in **DYCE Time Tracking**. If [attendances](/docs/web/tt/time-tracking/attendances.md) are not used, this switch should be deactivated in order to keep the user interface as clear as possible. ### Absences The three toggles **Create Absences**, **Edit Absences** and **Delete Absences** define which actions users can perform on absences. * **Create absences** Determines whether users are allowed to create absences in Time Tracking or not. * **Edit absences** Determines whether users are allowed to edit absences in Time Tracking or not. * **Delete absences** Determines whether users are allowed to delete absences in Time Tracking or not. These toggles are relevant if **DYCE Time Tracking** is connected to a third-party (HR) system. If absences are maintained outside DYCE and all three switches are deactivated, **[Absences](/docs/web/tt/time-tracking/absences.md)** are only displayed on the corresponding page in **DYCE Time Tracking**, but are taken into account when calculating resource availability in **DYCE Project & Resource Planning**. ## Authentication There are two ways to authenticate with **DYCE Connect**: with a regular *[user](#user)* from the *Microsoft Entra ID* or with a *[client](#clients)* for service-to-service authentication. ### User The user who sets up a new company in **DYCE Time Tracking** is automatically assigned the **Admin** role. All other users must be created manually for each company in **DYCE Connect**. Users are created in the **Administration** area on the **Users** page. New users are added from *Microsoft Entra ID* via the large *PLUS* button. Assign the corresponding [roles](#roles-and-permissions) to give users access to each area. #### Login The user logs in once per browser and device; the login is remembered for the next visit. If the user has access to only one area (Admin, Time Tracking), that area opens directly; with access to several areas, the user selects one. Logging in uses the last used company and environment, stored in local storage under the keys *company* and *instance*. If the stored environment no longer exists, for example because it was removed from local storage, the user must log in again. #### Guest login for external tenants {#guest-login} A B2B guest user, invited into a DYCE customer's *Microsoft Entra ID* tenant from another organization, can sign in against that specific tenant by adding a `?tenant=` parameter to the app URL. The value is the tenant's directory id (a GUID) or a verified domain, for example: `https://app.dyce.cloud/?tenant=customer.onmicrosoft.com` Sign-in then uses that tenant for the whole browser session, including later automatic token renewals. The parameter is only needed when signing in to a tenant other than the user's own (home) tenant, as is the case for a guest. Users signing in to their home tenant do not need it; without the parameter the standard multi-tenant sign-in applies, and a missing or invalid value is ignored. ### Clients Creating a client requires the **Admin** role. Open the *Administration* section and navigate to the **Clients** page, where clients can be created or edited. Select the *PLUS* button to add a client. Clients need *roles* to access application areas just like users. A client can be created without a resource and then has access to all time recordings. If the client has a resource assigned, all operations the client performs are scoped to that resource. To authenticate with a client, add the key from the overview (**Client Key**) to the *Authorization header* of the HTTP requests. The requests also need an X-Instance and X-Company header with the environment configuration. ``` Authorization: 'Bearer ' X-Instance: 'Sandbox' X-Company: 'CRONUS DE' ``` ## Roles and permissions {#roles-and-permissions} Permissions can be assigned via roles in **DYCE Connect**. Different areas are shown or hidden depending on the role. Roles must be stored just like users *per company*. To simplify the assignment of roles, several users can be selected and the desired roles assigned. To assign a role, one or more users must be selected and the **Edit user roles** *(pencil top right)* must be selected. In the following dialog, roles can be assigned or removed for the selected users. ### Admin For users with the **Admin** role, the **Administration** section is visible. They can perform all setups without restrictions. :::note Admin A user with the **Admin** role cannot revoke it or delete its own user. ::: ### Planning Users who wish to use project planning require the **Resource Planning** role. Without this role, the *Planning* area is not visible to the user. ### Time recording {#time-recording} To record time, a user needs the **Time Recording** role assigned. Without this role, the *Time Tracking* area is not visible to the user. In addition to the role, a **Resource** must be assigned to the user. Resources are created in Business Central and times are captured for the assigned resource. Resources are assigned in **DYCE Connect** in the **User** page. All time recordings created for a resource are visible to the user(s) who have this resource assigned. Therefore, each user should be assigned a separate resource. :::warning Users and resources Users with no resource assigned will not get access to time tracking! If two users have the same resource, they see each other's time recordings. There is no way to distinguish these time recordings between these users. ::: ## Delete DYCE company / environment To delete an environment or company, send the following information to support@dyce.cloud: * Tenant Id * Name of the environment * Company code * Admin's email (for queries) --- ## Supported Platforms # Browser **DYCE Connect** currently supports the following browsers: |Browser|Version| |:--|:--| |Edge|>=91| |Chrome|>=90| |Firefox|>=117| # Mobile devices Mobile devices are not yet supported in the form of a native app. However, the website is able to respond to the browsers available on the devices and display the content accordingly. In addition, it is possible to add a link to **DYCE Connect** to your home screen by tapping *Share* in your mobile browser and then tapping *To Home Screen*. --- ## Azure DevOps # Necessary prerequisites The **DYCE Time Tracking** extension for Azure DevOps will only work if Time Tracking is fully set up. This includes the creation of at least one environment or company respectively. The necessary steps are described in the following sections: * [Business Central setup](/docs/web/administration/setup-bc.md) * [Create DYCE Connect company](/docs/web/administration/setup-sync.md) * [Setup DYCE Connect](/docs/web/administration/setup-web.md) Once **DYCE Time Tracking** is set up completely, the Azure DevOps extension can be installed and set up. ## Installation [Install an extension](https://learn.microsoft.com/de-de/azure/devops/marketplace/install-extension?view=azure-devops&tabs=browser) in your organization. :::warning Important If the Time Tracking add-in is not displayed, pop-ups must be allowed. ::: ## Setup Once the installation is complete, the **DYCE Administration** page is available for setup. The page can be opened in the project under *Project Settings/Extensions*. To access and edit this page, you must have the required permission in Azure DevOps and the **Admin** role in **DYCE Time Tracking**. ### Select company Please check the user and organization details in **DYCE Environment**. Select the company for which the time recordings should be created. In the selection **Select company** all available companies are listed grouped by environment. :::warning Attention The selection determines in which company the time recordings will be synchronized. If the company is subsequently changed, all time recordings and work items remain unchanged and are not assigned to the new company. Furthermore, the service hooks must be recreated, if the company is changed. The Area Mapping is deleted to avoid false values in time recordings. ::: ### Create Service Hooks The action **Create Service Hooks** opens a dialog. A valid client key must be entered in this dialog. The key can be created in the [Clients](/docs/web/administration/setup-web.md) view in the admin area of **DYCE Connect**. The link from the dialog leads directly to the corresponding client. The client key requires neither a role nor a resource. In this case, it is also recommended not to specify an expiration date. Three service hooks are created: 1. *Create Work Item* synchronizes newly created work items. 2. *Update Work Item* synchronizes changes to the work items. 3. *Delete Work Item* deletes the work item in the DYCE backend and Dynamics 365 Business Central. :::warning Please check the company before creating a client key. The key will only work, if the Azure DevOps project is linked to the same company. ::: ## User and login The user must be assigned the **Time Recording** role and a resource in **DYCE Connect**. ## Language Azure DevOps is currently not available in German. Therefore, we refrain from detecting the browser language and provide the DYCE Time Tracking extension in English only. --- ## Jira # Necessary Prerequisites The **DYCE Time Tracking** extension for Jira only works if Time Tracking is fully set up. This includes the creation of at least one environment or company. The necessary steps are described in the following sections: * [Business Central setup](/docs/web/administration/setup-bc.md) * [Create DYCE Connect company](/docs/web/administration/setup-sync.md) * [Setup DYCE Connect](/docs/web/administration/setup-web.md) Once **DYCE Time Tracking** is fully set up, the Jira extension can be installed and set up, as well. :::info **Jira Software** and **Jira Work Management** Since **Jira Software** and **Jira Work Management** are very similar with regard to the **DYCE Time Tracking** extension, but **Jira Work Management** is less common, both tools will be included in the rest of this documentation whenever **Jira Software** is mentioned. ::: ## Installation [Install the extension](https://marketplace.atlassian.com/apps/1232996/dyce-time-tracking?hosting=cloud&tab=overview) via the [Atlassian Marketplace](https://marketplace.atlassian.com/) in your organization. Once the installation is complete, **DYCE Time Tracking** is generally available. However, before the extension can be used for time tracking, it must be selected for this purpose in the global settings. This can be done at any time, as the other settings of **DYCE Time Tracking** do not depend on this. To determine which time tracking is to be used, open the settings (administration icon, cogwheel) in the top right-hand corner of the screen and select **Issues**. In the page that opens, you will find the **Time tracking** item in the menu on the left (under *Issue Features*). Select *DYCE Time Tracking* as the **Time tracking provider**. Check and, if necessary, change the other settings in the **Global time tracking settings** section before you access the further DYCE Time Tracking settings via the *DYCE Time Tracking settings* link. This is located in slightly different places depending on the Jira product (**Service Management** or **Software**). In **Service Management**, the page is opened in the Project via *Project settings/DYCE Time Tracking*, in **Software** via *Project settings/Apps/DYCE Time Tracking*. To access and edit this page, you must have the required permissions (*Admin* role) in Jira and the *Admin* role in DYCE Time Tracking. :::warning Important If the Time Tracking add-in is not displayed, pop-ups must be allowed. ::: ## Different project structures in Service Management and Software Projects are available in both **Jira Service Management** and **Jira Software**, but they behave slightly differently in detail. If the Service Portal from **Jira Service Management** is in use, the tickets of all accounts (= customer logins) can be created for the same project, or separately for one customer project at a time. To map both scenarios, the mapping runs via the customer themselves. At the same time, **Jira Service Management** recognizes the principle of a *customer*. A pre-assignment of customer, project, project task and activity for time recordings can therefore be made within a (service) project per customer. **Jira Software**, on the other hand, does *not* recognize the principle of a customer. The mapping for time recordings can therefore only be made per (customer) project. We therefore recommend creating a separate project for each customer and making the pre-assignment in each project. ### Pre-assignment of time recordings In **Jira Service Management**, time recordings are pre-assigned per *customer*, in **Jira Software** per *project*. #### Jira Software In the *Project settings* in **Jira Software** under *Apps/DYCE Time Tracking*, in the *company assignment* area, select the company to which the time recordings for this project should be made. All available companies are listed in the selection field, grouped by environment. The *Project-Assignment* tab can be used to predefine **Customer**, **Project**, **Project Task** and **Activity**. It is not always necessary to predefine all fields. #### Jira Service Management In the *Project settings* in **Jira Service Management** for *DYCE Time Tracking* in the *company assignment* area, select the company to which the time recordings for this project should be made. All available companies are listed in the selection field, grouped by environment. The *Customer-Assignment* tab shows all customers (grouped according to the domain of the logins). The displayed name, which is predefined via the domain, can be changed individually. For each customer, **Customer**, **Project**, **Project Task** and **Activity** can be predefined here. It is not always necessary to predefine all fields. In addition to the pre-assignments for customers, a pre-assignment can also be made for internal purposes. If Jira is used internally, a pre-assignment can be created in the same way as for customers. The pre-assignment is displayed in the same area, if **Display internally** is set to *YES*. The domain can be used to determine, whether it is an internal issue. If the employee who creates the issue logs in with the same domain, that is used for Jira, it is an *internal employee* and the issue runs on the *internal* pre-assignment (if available). :::warning Caution The selection determines the company in which the time recordings are synchronized. If the company is changed, all time recordings remain unchanged and are not assigned to the new company. The pre-assignment of Customer, Project, Projecttask and Activity is not valid for the new company. Please create a new pre-assignment for the new Company. ::: ### Create WebHook The **Create** action in the *DYCE Time Tracking integration* area opens a dialog. A valid client key must be entered in this dialog. The key can be created in the [Clients](/docs/web/administration/setup-web.md) view in the administration area of **DYCE Connect**. The link from the dialog leads directly to the corresponding client. The client key requires neither a role nor a resource. In this case, it is also recommended not to specify an expiration date. A WebHook is created that reacts to the following events: 1. *Create Issue* synchronizes newly created issues. 2. *Update Issue* synchronizes changes to the issues. 3. *Delete Issue* deletes the issue in the DYCE backend and Dynamics 365 Business Central. :::warning Caution Please check the company before creating a client key. The key only works if the Jira Project is linked to the same company. The WebHook must be recreated, if the company has been changed. Please create a new client key in the new company and use it to set up the WebHook. ::: ## User and login The user must be assigned both the **Time Recording** role and a resource in **DYCE Connect**. --- ## Setup(Setup) # Setting up DYCE Time Tracking **DYCE Time Tracking** is part of the parent **[DYCE Connect Platform](/docs/web/introduction.md)**, which includes [Time Tracking](/docs/web/tt/welcome.md) as well as [Project and Resource Planning](/docs/web/prp/welcome.md). For **DYCE Time Tracking** there is an integration in [Azure DevOps](/docs/web/tt/setup/AzureDevOpsExtSetup.md) and the [Jira products](/docs/web/tt/setup/JiraExtSetup.md) from Atlassian, for each of which separate setups exist. ## Tasks The [Assigned Tasks](/docs/web/administration/setup-web.md#tasks) field on the **Settings** page in the **Administration** area specifies whether the assignment of resources to tasks should have an influence on the display. This setting only affects **DYCE Time Tracking**. ## Selection of Time Tracking forms The user has four **Time Tracking forms** to choose from. The Time Tracking Forms differ in the arrangement and displayed fields. **Compact**, for example, has no *Start* and *End* fields. The **Simple** time recording mask also omits the *Customer* field. The preview below the selection shows the selected mask. Changing the Time Tracking Form changes the display on the **Recordings**, **Incomplete** and **Templates** page. --- ## Absences # Absence By recording absences, companies can ensure that operational processes run smoothly. This helps to avoid bottlenecks and maintain productivity. Good absence management contributes to better planning of resources and minimizing negative impacts on the business. The ability to plan employees is directly linked to their availability. It is therefore important that the planning system, e.g. **DYCE Project & Resource Planning**, is aware of people's absences. This also helps to assess whether employees' time recordings for a period are complete. On the **Absences** page, employees can record and change their absences. The display of the considered period can be switched between *month* and *week*. Depending on the selected period, each day of the week or month is displayed in the list. To keep the display lean, each line corresponds to an absence. It contains the start and end date of the absence, the number of working days absent and the [Cause of Absence](#create-absence) or its description. Upcoming absences are displayed in the upper part of the list, past absences in the lower part. ## Create absence A new absence is created via the blue *PLUS* button in the top right-hand corner of the page. A dialog opens in which the cause of absence is first selected. The start and end date can then be entered or selected via the calendar. The system calculates the duration of the absence and - based on the working time model - the actual absence. The smallest unit for an absence is half a day. Absences for individual hours cannot be recorded. If a new absence overlaps with an existing absence, the system issues a corresponding message. Note: The selectable causes of absences are maintained in Business Central. ## Edit and delete absence In the overview of absences, a context menu is offered on the right-hand side of the list. This can be used to open and edit or delete an absence. ## Effects on DYCE Time Tracking No time recordings are expected for days with absences. The expected hours are reduced accordingly in the overview and in the list of time entries. In the time tracking calendar, absences are displayed as full-day appointments. ## Effects on DYCE Project & Resource Planning Regardless of whether they are transferred from an external system or recorded via **DYCE Time Tracking**, absences are taken into account when calculating [resource availabilities](/docs/web/prp/planning/people.md#utilization). They are also displayed in the work order calendar for central planning. ## Synchronization with third-party tools It is neither intended nor planned to map the functional scope of HR software in **DYCE Time Tracking**. The focus is rather on the organisation of capacities for planning and time recording. If extended functionalities such as holiday entitlements and remaining holiday days are required, corresponding software must be connected. This connection can be realised either via the Business Central API or the DYCE Connect Platform API using a [Client Key](/docs/web/administration/setup-web.md#clients). ### Settings Depending on whether **DYCE Time Tracking** is connected to a third-party (HR) system, the ability to record absences may need to be restricted. The settings required for this can be found in the [Administration](/docs/web/administration/setup-web.md#absences) area of **DYCE Connect**. --- ## Attendances # Attendance In many countries, the recording of daily working hours is required by law. Attendance tracking in **DYCE Time Tracking** enables all users to record the start and end of working time (duration of working time) as well as breaks. Attendance is objective, reliable and accessible. The attendance is recorded by the employees. Attendances can be recorded and maintained on the page of the same name. The display of the period can be switched between *month* and *week*. Depending on the selected period, each day of the week/month is displayed in a list. To make recording easier, the number of Time Recordings and the total duration are displayed on each day. Non-working days are shown in gray, days on which an attendance is to be created are shown in orange. Days, on which at least one attendance has been created, are marked in green. The recorded attendance and the expected attendance are displayed at the top right. This page is only available if it has been [set up](/docs/web/administration/setup-web.md) on the **Settings** page in the **Administration** section. ## Create an attendance Attendances do not have to be saved separately; this is done automatically for each change. To create a new attendance, simply enter a time in the Start field. The entry is analogous to the Start field in Time Recordings. If an attendance already exists for a day, another one can be created using the **Add Attendance** button. The button is automatically displayed when the mouse is positioned over the existing attendance. The same applies to creating additional breaks. ## Delete an attendance The delete button is displayed when the mouse is positioned over the attendance. When an attendance is deleted, the breaks are also deleted. ## Delete a break The button for deleting a break is displayed when the mouse is positioned over the attendance. :::tip Attendance in Time Tracking The recording of attendances in **DYCE Time Tracking** has the requirement of good usability for the person recording the attendance. There are a number of planned features that will further improve the user experience. Here are some examples: * Start, stop, pause function for the creation of attendances * Optimization for mobile devices * Connection to HR software * Display and creation of absences It is neither intended nor planned to map the functional scope of a HR software in **DYCE Time Tracking**. Attendances are synchronized to Business Central, but cannot be edited there. However, they can be retrieved from Business Central or using a [Client Key](/docs/web/administration/setup-web.md) from DYCE Connect. ::: --- ## Time tracking in Azure DevOps A time recording can be created in the tab **DYCE Time Tracking**. It is available in all types of work items. Creating a [time recording](/docs/web/tt/time-tracking/time-tracking.md) in Azure DevOps does basically not differ from creating it in **DYCE Time Tracking**. The functionality of fast entry via stopwatch and templates are not available in Azure DevOps. Instead of the stopwatch, a time tracking can be created with pre-populated **Customer**, **Project**, **Project task**, **Activity** and **Description** in DYCE Fast Tracking. :::info Note DevOps is currently not available in German. Therefore, we refrain from detecting the browser language and provide the **DYCE Time Tracking** extension in English only. ::: ## DYCE Fast Tracking DYCE Fast Tracking is the fastest way to create a time recoding. It can be used in every work item (Epic, User Story, Task, etc.). Clearly visible in the Details tab, a new time recording can be created with the **Plus** button, once a duration has been inserted. The **Description** is automatically generated from the type, number and title of the work item. The assignment of **Customer**, **Project**, **Project Task**, and **Activity** is determined from the **Area**, if the pre-assignment was set up. The User can change the **Activity** and create time recordings. The last 20 changes to the activity are saved on creating the time recording. These are used to pre-populate the Activity the next time the user creates a time recording in that work item. If **Original Estimate** and **Remaining** is populated in a work item, **Remaining** and **Completed** are automatically updated. :::info Note The **Activity** can only be changed if a project task with job planning line is pre-assigned. If the work item is not saved, changing the activity and creating time records might be prevented to avoid incorrect or missing pre-assignments. The automatic calculation of **Remaining** and **Completed** will be visible in the Chrome Browser only after reloading the page. ::: ## DYCE Time Tracking in work items The tab **DYCE Time Tracking** is displayed in every work item. In this tab, new time recordings can be created in **New**. The **Description** is pre-filled with the type, number and title of the work item. The fields **Customer**, **Project**, **Project task** and **Activity** are pre-populated with values of the Area mapping. If the **Original Estimate** and **Remaining** is filled in a Task, Remaining and Completed will be updated automatically. :::tip If a new Time Recordings cannot be created, there may be unsaved changes in the work item. If changes are made in the following fields, the work item must be saved before a new time recording can be created: * Titel * State * Area * Iteration * Assigned to * Work Item Type ::: In **All** all time recordings, that have been created in that work item, are displayed. The time recordings are grouped by resource. A total is calculated for each group. The total allows you to see who has worked on the work item and for how long at a glance. In **Incomplete** all time recordings are displayed, in which an important information is missing. Which information is missing is indicated by the *red star* and at the hoover above the status. ## Pre-assigning values with the Area The **Customer**, **Project**, **Project task** and **Activity** fields can be pre-assigned by selecting an Area in the work item. ### Area path In Project Settings, an [Area path](https://learn.microsoft.com/en-us/azure/devops/organizations/settings/set-area-paths?view=azure-devops&tabs=browser) can be created in **Project configuration** (*Boards*) in the **Areas** tab. ### Area Mapping The areas mapping can be created in the **Project Settings**. Here in **DYCE Administration** (*Extensions*) in the tab **Area Mapping** the assignment of Customers, Projects, Project tasks and Activities to Area Paths can be created. The selection is limited to the correct options in terms of content and is inherited to the layers below. For example, it is not possible to select a Project that does not belong to the selected Customer. ### Use of Area Mapping The Area Path can be selected in all work items in the **Area** field. When creating a time recording, the pre-assignment values are determined from the Area Mapping and used to fill the corresponding fields in the time recording. When creating a time recording, the preallocation (*area mapping*) is determined from the area path and used to fill the corresponding fields in the time recording. :::tip If the Area Mapping is done and the area is assigned to a work item, every user can create time recordings without the need to search for the right Project Tasks. ::: --- ## Calendar The page shows Time Recordings and appointments in one calendar. Time Recordings can be created directly in the calendar and on the appointments. ## Display Time Recordings are always displayed in green and on the left within the respective day. If the [read permission](#exchange) has been granted, the appointments from the Exchange calendar will be displayed. If the mouse is hovered over an appointment, it and the related time recording will be highlighted. The same happens when the mouse is hovered over the time recording. At the top of the calendar, the day of the week and the total Time Recordings for that day are displayed. On days (incl. weekends and holidays) that are non-working according to the working time template or Base Calendar, the date and weekday are displayed in red and the calendar area is slightly gray. Time Recordings can also be created on non-working days. ## Navigation The header of the page displays a number of information and options for navigation. On the far left below the page name, the number of appointments without time recording is displayed. *All day* and *private* appointments are not counted. In the middle, there is the navigation to select the desired calendar week. Next to the date, the arrow keys can be used to jump to any week. Clicking **Today** will jump back to the current week. Below this navigation the date of the currently selected week is shown. Next to it is the display option for the calendar: here you can switch between the **whole** week and the **working** week. On the far right, the target and actual time recording of the selected week is displayed. ## Create Time Recordings Time Recordings can be created either at an appointment or by marking the desired time period in the calendar. ### Create Time Recordings at appointments Exactly one Time Recordings can be created per appointment. There are three different ways to do this: 1. From a certain duration of an appointment, a blue plus is displayed. This can be used to create the time recording directly with one click. 2. Alternatively, right-click on the appointment to open a context menu in which a new time recording can be created and opened with the **Create time recording** option. 3. With a left click, general information about the appointment can be opened. In the small overview there is a small plus in the upper right corner, which is also used to create and open a new time recording. The options for creating a time recording on an appointment are no longer displayed once a time recording has been created. Time Recordings cannot be created for all-day and private appointments (see above). Creation without an appointment is possible without restrictions (see below). When creating the Time Recordings via one of these ways, the start, end and the description are taken from the appointment. :::info Link between time recording and appointment If a time recording is moved to another day, it will be treated as if it no longer belonged to the appointment. The plus and the other options for creating Time Recordings will be displayed again. If the time recording is moved back to the day with the original appointment, it will belong to that appointment again. ::: ### Creating Time Recordings without an appointment Time Recordings can also be created without an appointment. This is done by marking a period in the calendar. In the Time Recordings, the start and end are automatically filled with the times of the marked area. In the calendar can be marked in increments of 15 minutes. By right clicking on the time recording and selecting the **Duplicate Time Recording** option, it can be copied. The new time recording can be dragged & dropped to the desired day and time. If the **Shift** key is held down while moving (drag & drop) the time recording, the original time recording will be copied and not moved. ## Edit and delete Time Recordings The fields and their functions in the Time Recordings mask do not differ between the [Time Recordings](/docs/web/tt/time-tracking/time-tracking.md) page and the calendar. Time Recordings can be opened in the following ways: * Click on the status icon * Double-click * Right-click and **Edit Time Recordings** * Left-click and click on the clock icon :::info Move Time Recordings If the Time Recordings are moved by **Drag & Drop**, the start and end are automatically reset. The billable duration will not be recalculated because neither duration nor Activity will change. ::: Time Recordings can be deleted in the following ways: * Right click and **Delete Time Recordings** * Left click and click on the delete icon * Remove key on the keyboard Released Time Recordings cannot be edited or moved. If an appointment is moved or deleted, the Time Recordings will not change. It will neither be moved nor deleted. ## Appointments Appointments are read exclusively from the Exchange calendar. They are not saved and cannot be edited or moved. The color representation of the appointments depends on the type: |Type|Colors| |:--|:--| |Busy|Purple| |Free|Orange| |Working elsewhere|Turquoise| |Tentative|Gray-Purple hatched| |Away|Gray| |With reservation|hatched| ## Displaying the Exchange calendar {#exchange} The Exchange calendar of the logged-in user is displayed, provided that the user has granted read permission. The first time the calendar is opened in the Time Tracking app, each user is asked for read permission for the Exchange calendar. If the user grants permission, all appointments from the Exchange calendar are displayed in Time Tracking and can be used for time recording. The appointments are not stored in the Time Tracking app and cannot be edited there. The permission can also be granted subsequently in the **[Settings](/docs/web/administration/customization.md)** in the **Time Recording** tab. Alternatively, a user with the *Microsoft Entra* role **Application Administrator** can grant read permission for the entire organization. In this case, the individual users are no longer asked. This global consent is granted via the *Enterprise application* **DYCE** (with the application ID *5ac2d7d3-ff4d-4a8a-a1ff-204580a4696e*) in *Microsoft Entra*. For this purpose, access to *Calendars.Read* must be permitted in the related *Permissions*. --- ## Dashboard # Overview The overview shows several reports. At the top of the page, a navigation menu and the totals of the time recordings in the currently selected period are displayed. All reports are calculated per resource. :::info Resource Person Defaults Some of the calculations are based on the the **Work-Hour Template** and **Base Calendar** in the [Resource Person Defaults](/docs/web/administration/setup-bc.md#resources) of the resource. If these are not set, a base line of seven days per week with eight hours per day (7x8) is assumed. ::: ## Navigation A navigation menu is displayed at the top of the page. In this menu you can navigate to the current period with **Today**. With the arrows left and right it is possible to switch to the previous or next period. Below the navigation menu the start and end date of the selected period is displayed. Using the calendar next to the date it is possible to jump to another period. In the selection next to the calendar the period (*week*, *month* or *year*) can be selected. On the right side the sum of the duration of the time recordings and the target working time (capacity) is displayed. The sum of the target and actual times recordings is calculated for the selected period length. ## Time Recordings If the period *Week* is selected, the target and actual working time per day is displayed. Non-working days (e.g. weekends and holidays) are only displayed if there is a time recordings for these days. The actual working time is calculated from the sum of the duration of the time recordings of the respective day. Clicking on the target or actual working time opens the time recordings for the corresponding day. The *PLUS* button below the graph can be used to create a new time recordings for this day. If the period *Month* is selected, the target and actual working time per calendar week is displayed. Also, calendar weeks that are only partly in one month are displayed. The complete calendar week is taken into account and not only the part in the respective month. If the period *Year* is selected, the target and actual working time per month is displayed. ## Projects The five **Projects** for which the user has recorded most of its time (sum of duration) are displayed in the evaluation. The total duration is calculated for the selected period. If time recordings have been created for more than five projects or if no project is specified in the time recordings, they will be summed up and displayed in an extra item *Others*. *Others* will always displayed last. The duration is used as the basis for the calculation. ## Billable / Non-Billable Duration The sum of billable and non-billable time recordings of the user is displayed in this evaluation. Non-billable time recordings are categorized - depending on the billing type or **Non-billable Reason** - as *Internal*, *Good Will*, and *Warranty*. A time recording is partially or completely non-billable if the duration is greater than the billable duration. The difference between the duration and the billable duration is the non-billable duration and is shown with the specified **Non-billable Reason** in the evaluation. The **Billable duration** of the time recording will be reported as *Billable*. The billable duration can be greater than the duration. Besides manual interventions by the user, the billable duration can be increased by rounding or surcharges. Accordingly, the sum of the parts in the **Billable / Non Billable Duration** evaluation can be greater than the duration of the time recordings (top right). ## Activities The ten **Activities** for which the user has recorded most of its time (sum of duration) are displayed in the evaluation. Activities with the same description are summed up. Different **Time & Travel models** are irrelevant for the calculation. The total duration is calculated for the selected period. If time recordings have been created for more than ten Activities or if no Activity is specified in the time recordings, they will be summed up and displayed in an extra item *Others*. *Others* will always displayed last. The duration is used as the basis for the calculation. --- ## Incomplete Time Recordings # Incomplete time recordings All incomplete time recordings are displayed in the page **Incomplete**. For a time recording to be considered complete, at least duration, description, customer, project and task (Project Task in Business Central) must be filled in. If the mentioned fields are filled the time recordings will be no longer shown in the page **Incomplete**. :::tip [Templates](/docs/web/tt/time-tracking/templates.md) can be used to complete time recordings. ::: Time recordings are marked as incomplete because, among other things, the time recordings cannot be released by the project manager in Business Central / **DYCE Project Billing** without specifying the project task. When releasing, the project manager must also ensure that the time recordings are assigned to the correct activity (Project Planning Line). In general, time recordings cannot be released, posted, or invoiced until they are complete. :::warning Time recordings without a task (Business Central) Time recordings without a task (Project Task in Business Central) are not displayed in the page **[Project Billing](/docs/pb/project-billing.md)** in **DYCE Project Billing**. For controlling purposes, you can check in the Time recording page in Business Central / **DYCE Project Billing** with a corresponding filter whether a Project Task has been assigned to all time recordings. ::: --- ## Time tracking in Jira # Time recordings in Jira Service Management and Jira Software The [creation of time recordings](/docs/web/tt/time-tracking/time-tracking.md) in Jira is basically the same as in **DYCE Time Tracking**. Time recordings can be created in the tickets in **Jira Service Management** and the issues in **Jira Software** via the **DYCE Fast Tracking** add-in. This is also possible via the **Work log** tab in the **Activity** area. Existing time recordings can also be completed and checked here. The functionality of fast entry via stopwatch and templates are not available in Jira. Instead of Fast Tracking by stopwatch, time recordings can be created with default values for **Customer**, **Project**, **Job Task**, **Activity** and **Description** in DYCE Fast Tracking. ## DYCE Fast Tracking DYCE Fast Tracking (in the right sidebar) is the fastest way to create a time recordings. It can be used in any ticket or issue. Alternatively, a new time recordings can be created via the **Work log** tab in the **Activity** section using the *Create* button. The **Description** is automatically generated and predefined from the type of activity, number and title. It is used for simplification and can be changed by the user. The pre-assignment to **Customer**, **Project**, **Project Task** and **Activity** is made using a *[mapping](/docs/web/tt/setup/JiraExtSetup.md#pre-assignment-of-time-recordings)* or *[assignment](/docs/web/tt/setup/JiraExtSetup.md#pre-assignment-of-time-recordings)*, if this has been done. If this is not the case, the assignment can be created using the button of the same name. As this is an override in the user context, the selection per user and ticket/issue is saved in the background and reused the next time. If the **Original estimate** is filled in an issue, **Time remaining** and **Total** are automatically updated. **Total** is displayed in green until 80 percent of **Original estimate** is reached. The display then turns yellow. If **Original estimate** is exceeded, **Total** is displayed in red. :::info Note The **Activity** can only be edited if a **Project Task** incl. Project Planning Lines is predefined. If the last change has not been saved, changing the Activity and creating time recordings is prevented in order to prevent incorrect or missing mapping. The automatic calculation of **Original estimate** and **Time remaining** is only carried out in the Chrome browser when the page is reloaded. ::: ## DYCE Time Tracking in Service Management and Software The **Work log** tab is displayed in every process. New time recordings can be created here via *Create*. The **Description** is automatically generated and predefined from the type of process, number and title. It is used for simplification and can be changed by the user. The assignment to **Customer**, **Project**, **Project Task** and **Activity** is determined on the basis of a mapping or assignment, if this has been made. If this is not the case, the assignment can be created using the button of the same name. As this is an override in the user context, the selection per user and ticket/issue is saved in the background and reused the next time (see above). If the **Original estimate** is filled in an issue, **Time remaining** and **Total** are updated automatically. All time recordings for the respective issue are displayed in the **Work log** tab. The time recordings are grouped by user (employee) and totaled. The total shows at a glance how long the process was worked on in total. Incomplete time recordings are marked with a *red exclamation mark*. These are time recordings in which important information is missing. ## Locked Work Orders {#locked-work-orders} A Jira item is backed by a [Work Order](/docs/web/tt/time-tracking/work-order.md) in DYCE. When that Work Order is locked, time can no longer be recorded against it. In **DYCE Fast Tracking**, the entry fields are replaced by a note that the Work Order is locked, and the **Advanced** and **Save** buttons are disabled. In the **Work log** tab, the *Edit* and *Delete* actions are disabled for the affected time recordings. ## Pre-assignment using the mapping The **Customer**, **Project**, **Project Task** and **Activity** fields can be predefined using a [mapping](/docs/web/tt/setup/JiraExtSetup.md#pre-assignment-of-time-recordings). Every user can create his own, user specific pre-assignment per ticket/ issue. If the user has create a user specific pre-assignment, it will be used on creating time recordings. Otherwise the general pre-assignments will be used. ### Use of the mapping Related to an activity to a project or to a customer, time recordings can be predefined (see above). When an activity is created, the preallocation is automatically adopted if it exists. If the mapping is not complete, the assignment can be created using the button of the same name. The preallocation is also applied when creating a time recordings via the **Work log** tab. :::tip With well-maintained mapping, users can do their time recordings without having to search for the right Project Tasks. ::: --- ## Tasks The **Tasks** page displays all tasks that have been assigned to your resource. The assignments come either from the **[project plan](/docs/web/prp/planning/project-card.md#project-resources)** in **DYCE Project & Resource Planning** or are made in Business Central in Project Tasks. ## Setup Depending on the [setup](/docs/web/administration/setup-web.md#tasks), the use of tasks can be optional or mandatory. ## Creating tasks Tasks can be created in Business Central only. To do so, navigate to a **Project Task** with a budget for services in a Project. Using the *Assist Edit* or the *Line Menu*, the **Assigned Resources** action can be used to open the page **Assigned Resources**. The page displays all resources and the time periods, for which they have been assigned to the Project Task. In order for a Resource to be assigned to a Project Task, there must be at least one Project Planning Line with Line Type **Budget** and a Service Billing Type. The Service Billing Type is set in the item. Items that are used for Services have a Service Billing Type. Enter the following values to create a task for a user: * **Resource No.** Specifies the resource to be scheduled. This field must always be filled. * **Name** Shows the name of the resource. * **Scheduled Start Date** Indicates the earliest date the resource will perform the task. * **Planned End Date** Specifies the latest date, on which the resource will execute the task. * **Project No.** Shows the project no. for which the assignment is made. The Project cannot be changed. * **Project Tasks** Shows the project task no. for which is being planned. The Project Task cannot be changed. * **Project Planning Line No.** Shows the Project Planning Line number, for which planning is in progress. If there is more than one Project Planning Lines, planning on that level is potentially very helpful. The creation of tasks in **DYCE Time Tracking** is currently not possible. :::info Duplicate assignments are prevented. A resource cannot be scheduled twice for a Project Task or Project Planning Line in the exact same time period. Assignment in different time periods is of course possible. ::: ## Filter lookups in time recordings by assigned tasks Lookups in time recording and templates can be filtered by assigned tasks. If the filter is applied, the user will only see entries, for which he is assigned. Tasks can be assigned to Project Tasks and Project Planning lines. If a user is assigned to a Project Task, the matching Customer, Project, and Project Task will be displayed in the lookups. The user can freely select from the Activity. This means that the user can choose from all Project Planning Lines of the Budget type that include a Service Billing Type. If the user is assigned to a Project Planning Line, he is automatically assigned to the Project Task. In addition to the filter on Customer, Project and Project Task, the Activities are also filtered. The user can only select from the Activities that are related to the Project Planning Line to which he is assigned. If the filter is set as *Optional*, the user can activate and deactivate the filter. The setting will be saved. With the filter applied, the user can noticeably narrow down his selection and make creating a time recording easier. If the user wants to create a time recording for a Project, for which he has not been assigned, he can easily unassign the filter. ## Display of tasks If the user's resource is entered in **Resources Assigned** in Business Central and the status of the Project Task is *open*, the assignment is displayed as Tasks in **DYCE Time Tracking**. ### Grouping and sorting Tasks are grouped by job (project). For each Project, all Tasks, that are assigned to its own Resource and whose **Project Task** has the status *Open*, are displayed. The groups are sorted by project number. Tasks are sorted by start date. The grouping can be changed to **Customer** in the user settings. With this grouping, the tasks are displayed per customer and sorted by Project and then Start Date. ### Without date The field controls whether tasks without start and end dates are displayed. Tasks that have a start date, end date or both are not affected by this setting. ### Search In the search you can search for **Customer**, **Project No.**, **Project Description** and **Project Task**. The search is not deleted when leaving the page. This makes it possible to create a Time Recording and come back to the tasks without having to re-enter the search. ### Planned date If a date is inserted here, all tasks will be filtered by it. The system checks whether the **Planned date** is within the start and end dates of the task. If the start or end date is not specified, the earliest or latest possible date is assumed. If both start and end dates are missing, the task will be excluded. *t* can be used as a shortcut for the current date (today). :::info Example |task| start- enddate| |:--|:--| |Task 1| 01.12 - 31.12.2022| |Task 2| - 31.12.2022| |Task 3| 01.12.2022 -| |Task 4| -| * Planned date: 01.12.2022 All three tasks are displayed. * Scheduled date: 31.12.2022 All three tasks are displayed. * Scheduled date: 01.11.2021 Task 2 is displayed. * Scheduled date: 01.01.2023 Task 3 is displayed. * Scheduled date: 08.12.2022 All three tasks are displayed. ::: ## Create Time Recording In each task there is a **New Time Recording** button. Before the time recording can be created a date must be selected. In the dialog for the date selection are also a **Cancel** and **Save** button as well as the option **Open new time recording**. With **Save** a new time recording is created. If the option **Open new time recording** is selected, the Time Recordings page is opened immediately and the new time recording is displayed. :::info If you switch to the **Time Recordings** page while creating the time recording, you have the option to switch back to the same scroll position in the **Tasks** page. This allows you to seamlessly continue working and create more Time Recordings from the tasks. The **Back** button at the top next to the plus button, switches to the original position in the tasks. ::: --- ## Templates Templates are the ideal tool for capturing time recordings quick and easy. Time recordings can be completed by templates or created directly from a template. Templates are displayed in the page with the same name. ## Creating templates Templates can be created based on a time recording and in the **Templates** page. The action *Save as Template* in the context menu of time recordings creates a template from that time recording. In the **Templates** page, new templates can be created directly at the categories or via the **Add Template** action. The action **Copy Template** from the context menu can be used to copy a Template. When a Template is copied, a category has to be selected. ### Editing templates Templates can be edited in the **Templates** page. A date cannot be entered in templates, though. Except for that fact templates behave the same as [time recordings](/docs/web/tt/time-tracking/time-tracking.md). **Move up** can be called in the context menu to move the Template up by one position. The action **Move template** can be used to move the template to another category. ### Organizing by categories **Templates** can be distinguished by categories. New categories can be created on the **Templates** page. Templates are grouped by category. Multiple templates can be assigned to a category. If the template is created for a category, it will be used automatically. Otherwise, a category must be selected for the template. If there is no category, it will be created automatically. :::tip Categories are ideal for organizing and grouping templates. Consultants and developers usually create categories (and templates) for their current projects. In product development, categories are often created per product or major feature. A category for internal meetings, organization, etc. is quite popular as well. ::: The order of categories can be changed using the action **Move up** in the context menu. The category and all its Templates will be moved up one position. The Templates are displayed in the same order as on the **Templates** page. Changing the order can be very helpful for creating time recordings. ### Editing categories Categories can be renamed and deleted using the actions in the context menu. If a category is renamed the templates remain assigned. If a category is deleted all associated templates will be deleted as well. ## Using templates in time recordings In the editing mask of a time recordings a selection of templates can be called up (*Alt+T*). The Templates are displayed in the same order as on the **Templates** page. If a template is selected, the data from the template will be transferred to the time recording. Existing data in the time recording will not be overwritten. For example, if the duration and description are filled in a time recording, they will not be overwritten by the template. In this case, information on the customer, project, task and activity can be filled in using the template. :::tip Simplified time recording The use of templates allows simplified time recording. If a time recording is created by the stopwatch, the duration and possibly the description are already filled in. With a template, the time recording can be completed in a few clicks. Applying a template to an empty time recording and then only adjusting the description or duration is also a popular way to capture time recordings. ::: Time recordings can be created directly in the **Templates** page. The **New Time Recording** action on the template opens a calendar to select a date. The selection is necessary because no date can be stored in a template. With **Save** the time recording will be created for the selected date. With the **Open new time recording** indicator, the time recording can be opened and edited directly on the selected date. The setting of the indicator is saved for future use. --- ## Time Recordings # Time recordings The page displays your time recordings and the days of the selected week. Days with no target working time are not displayed, unless there are time recordings for these days. The time recordings are grouped by days. On the given day, the time recordings are sorted by Start. If Start is not filled, the time recordings are sorted in the order of creation. Each time recording shows the ratio of its recorded time to the target working time; for each day, the durations are summed and shown against that day's target. ## Create new time recordings Time recordings can be created in several ways: 1. **Stopwatch** The stopwatch is called up by clicking on the **Stopwatch** icon on the upper right-hand side or using the keyboard shortcut *Alt+S*. A description can be entered in the opening box. **Start** the stopwatch with the corresponding action. With the keyboard shortcut *Ctrl+Enter* the stopwatch is started directly. As soon as the stopwatch is running, it is displayed in the browser tab and next to the stopwatch icon. **Save** (*Ctrl+Enter*) creates a new time recording with start and end time and the entered description. **Delete** does not create a time recording. 2. **Create new time recording in the menu** The big **PLUS** button in the page **Recordings** creates a new time recording for today. Start will default to the latest end. 3. **Create new time recording on the day** In front of each day is a **PLUS** button. This button creates a new time recording on that day. Start will default to the latest end. 4. **Save & New** In each time recording **Save & Close** or **Save & New** can be selected. **Save & New** can be found in the dropdown menu. The action saves the current time recording and creates a new one for the same day. 5. **Dashboard** The **PLUS** button underlying each day of the **Overview of time recordings** will create a time recording for the respective day. The new time recording is immediately displayed and can be edited. 6. **Templates** In the [Templates](/docs/web/tt/time-tracking/templates.md) page, templates for Time Recordings can be created and saved. The templates can be used to create or complete Time Recordings. 7. **Tasks** The [Tasks](/docs/web/tt/time-tracking/tasks.md) page displays all assigned tasks. Time Recordings can be created based on these tasks. 8. **Calendar** In the [Calendar](/docs/web/tt/time-tracking/calendar.md) page, all appointments from the Exchange Calendar will be displayed if the [read permission](/docs/web/administration/setup-web.md) has been granted. The appointments can be used to create Time Recordings. Alternatively, Time Recordings can be created by marking a period in the calendar. 9. **Copy** Time Recordings can be copied using the **Copy** action in the context menu of the Time Recordings. When copying Time Recordings that were created in Azure DevOps or Jira, the connection to the related work item or issue is not copied. ## Fields in time recordings Time recordings are opened for editing with a single click. The following fields are available in the input mask: - **Start** The (optional) starting time of the recording. :::tip Input formats Type `n` for the current time, or digits without a separator: - 1–2 digits = hours: `8` → 08:00, `15` → 15:00 - 3–4 digits = hours and minutes: `830` → 08:30, `1530` → 15:30 Leading zeros are accepted (`08` is the same as `8`). ::: - **End** End is calculated automatically when Start and Duration are entered. The input is analogous to Start. - **Duration** If the Start and End fields are filled in, the duration is calculated automatically. The break is subtracted from the duration. :::tip Input formats Otherwise, enter the duration as digits or a decimal: - 1–2 digits = hours: `1` → 1:00, `10` → 10:00 - 3–4 digits = hours and minutes: `130` → 1:30, `100` → 1:00, `0130` → 1:30 - Decimal hours: `1,5` → 1:30 A leading zero treats the input as minutes instead of hours: `01` → 0:10, `010` → 0:10, `001` → 0:01. ::: - **Break** Only available when Start and End are filled. Input format matches Duration. - **Description** A free-text description of the activity. Click the *pencil icon* in the lower-right corner of the field or press *Alt + O* to open a larger editor. - **Customer** The customer for this recording. Selecting one restricts the Project list to projects where this customer is the Sell-to Customer in Business Central; if only one project matches, it is filled in automatically. - **Project** The project for this recording. Selecting one restricts the Project Task list. Projects are maintained in Business Central. In the **Simple** time recording mask the Project list is not filtered by customer, since Customer is not shown there. - **Project task** The task within the project that this recording belongs to. Its behaviour depends on whether a Work Order is selected, and if so on the work order's [Budget Type](/docs/web/tt/time-tracking/work-order.md#invoicing) — see the cases below. Without a work order: - The list shows all available Project Tasks from the customer's project. Locked or closed Project Tasks are hidden. - The sorting of the list is based on the [setup](/docs/web/administration/setup-web.md) defined by your administrator. With a work order of **Budget Type Open**: - The list still shows all Project Tasks from the work order's project. - Project Tasks that already have a Work Order Line on this work order are marked with a small **blue star** in the lookup — a hint that the budget is already set up for them. - You can also pick an unstarred Project Task. A Work Order Line is then created in the background when you save the time recording — you don't see this happen in the form. With a work order of **Budget Type Project**: - The list is restricted to Project Tasks that already have a Work Order Line on this work order. - If the work order has no Work Order Lines at all, the Project Task and Activity fields are disabled and the time recording cannot be saved. The planner has to add a Work Order Line first. Auto-fill shortcuts (both Budget Types): - If the work order has exactly one Work Order Line, Project Task and Planning Line are filled in for you as soon as you pick the work order. - If the matching Work Order Line has a default Activity, that activity is filled in too — and stays editable. - **Activity** An activity pairs a project planning line (the budget the recording draws from) with a [Time & Travel Model](/docs/web/administration/setup-bc.md#time--travel-model) line. That line **presets** whether the recording is billable and how the **Billable Duration** is rounded; the recording's final status follows its **Billable Duration** (under *show more*), which you can override at any time. The Time & Travel Model is assigned on the [Project Card](/docs/pb/masterdata/project.md) in Business Central. :::info Billing status symbols The symbol on each activity shows the billing it would preset: - $ (green): presets the recording as billable - $$ (green): billable, and surcharges apply - $ (grey): presets the recording as non-billable ::: When a Work Order is selected (see the **Work Order** field below), the Activity lookup behaves like the Project Task lookup: under Budget Type Open every activity is shown and the ones already backed by a Work Order Line on this work order are marked with a small **blue star**; under Budget Type Project the lookup is restricted to Work-Order-Line-backed activities. If the matching Work Order Line carries a default Activity, it pre-fills when you pick the Project Task and stays editable. - **Work Order** Select the corresponding [work order](/docs/web/tt/time-tracking/work-order.md) for this time recording. The Work Order field interacts with the Customer, Project, Project Task, and Activity fields to speed up your workflow: - Filtering: The list of available work orders is automatically filtered by the already selected Customer and Project. - Auto-filling: Conversely, selecting a Work Order first will automatically fill the Customer and Project from the work order. Project Task, Planning Line, and Activity also auto-fill when the work order has exactly one Work Order Line. - Search: You can search for a work order by typing in the field. The search includes the Work Order's No., Title, Id, and other related details. - View Details: Click the **work order icon** (available in the field and the lookup list) to open the detailed Work Order Card without leaving your time recording. When the selected work order has **Budget Type Project**, the Customer and Project fields on the time recording are locked to the work order's values, and the Project Task / Planning Line / Activity selection is constrained to existing Work Order Lines — see the **Project task** field above for the full behaviour. When the work order has **Budget Type Open**, Customer and Project remain editable; on an Open work order that has no Customer or Project yet, the first time recording fills those values into the work order. For a **Sub-Work Order** without its own Work Order Lines, filtering and auto-fill use the lines of its parent Billing Work Order automatically. - Selecting **show more** displays additional fields: - **Date** Defaults to the date of the day the recording is created on. :::tip Input formats - `t` → today - Two-letter day name (`Mo`, `Tu`, `We`, …) → that day of the current week - Digits without separators are read as day, month, year (current year/month assumed when omitted): - `01` → 1st of the current month - `0102` → 1 February of the current year - `01022026` → 1 February 2026 - Or type the full date with separators: `01.02.2026` ::: - **Billable Duration** The portion of the duration that will be invoiced, and the value that decides the recording's billable status: greater than zero makes it *Billable*, zero makes it *Non-Billable*. If an activity is selected, its Time & Travel Model line presets and rounds this value; otherwise it defaults to the full duration. You can override the preset manually at any time. *Note:* When surcharges apply, the field becomes read-only (shown with a lock icon) and is set to the duration plus the surcharge duration. - **Non-Billable Reason** Filled in automatically when the Billable Duration is less than the Duration. The reason comes from the activity's Time & Travel Model line, or defaults to *Internal* if no activity is selected. - **Disable surcharges** Visible only when the project has a surcharge model. Turn it on to skip surcharge calculation for this specific recording. - **Additional Service** Books a flat-fee add-on on the recording. Only available once a Project is selected; the lookup lists the Additional Services of that project. See [Additional services](#additional-services) for details. ## Surcharges A surcharge is an additional fee applied for work performed outside regular business hours, such as evenings, nights, or holidays. **DYCE Time Tracking automatically** calculates surcharges based on the surcharge model defined in the Project in Business Central. For detailed information on configuring and managing surcharges, please refer to the [Surcharges Documentation](/docs/pb/surcharges.md). Whether surcharges are applied to a time recording is indicated in the activity field. If the activity displays the symbol $$, surcharges are applied. If only the symbol $ is shown, no surcharges are applied. If no activity is selected, surcharges are not applied. Users can override the automatic surcharge calculation for individual time recordings by using the **Disable surcharges** toggle in the time recording. This option is available under the "show more" section of the time recording and can be set in cases where surcharges would normally be applied according to the project settings, but should be excluded for that specific entry. ## Additional services An Additional Service is a flat-fee add-on — for example a one-off service charge or a flat fee for travel expenses — that you book on a time recording alongside the time you record. The available Additional Services are defined per project in Business Central. Select an Additional Service in the **Additional Service** field under the *show more* section of the time recording. The field behaves as follows: * It is only available once a **Project** is selected. Changing or clearing the project clears the Additional Service. * The lookup lists only the Additional Services of the selected project. You can search by description and Project Task description. * Additional Services are kept separate from regular work: they do not appear in the Activity, Planning Line, or Project Task lookups, and the Additional Service is never set automatically — selecting a Work Order does not prefill it. * It is editable on new and existing open time recordings. It cannot be set or changed while the related Project Task is closed or locked for time recording. In the time recording form and list, recordings that carry an Additional Service are marked with a **+** icon. An Additional Service is always invoiced as a billable flat fee, independently of whether the recorded time itself is billable. For setup, posting, and invoicing details, see the [Additional Services documentation](/docs/pb/professional-services/additional-services.md). ## Status of time recordings Every time recording has a status. While one or more mandatory fields are still missing, it is [Incomplete](/docs/web/tt/time-tracking/incomplete.md). Once the mandatory fields are filled, the recording becomes either *Billable* or *Non-Billable* — shown as a label next to the *show more* / *show less* toggle: * **Billable** (green $ icon) — the recording will be invoiced to a customer; its billable duration is greater than zero. * **Non-Billable** (grey $ icon) — nothing will be invoiced because the billable duration is zero, although time was recorded. When an Additional Service is selected, a further label appears right next to the billing label, showing the Additional Service description with a **+** icon. ## Budget/quantity display in time recordings Time Recordings display the budgeted quantity of project planning lines and the amount of budget already used. This display allows you to see if and how many hours / days of the budget are still available. When a time recording is booked against a Work Order, the **Reserved Qty.** of the matching Work Order Line is the budget the time recording draws from — visible on the work order's [Invoicing tab](/docs/web/tt/time-tracking/work-order.md#invoicing). If the line's Reserved Qty. is 0, no exclusive reservation is in place and the whole Project Planning Line budget is available, shared with any other work orders that use the same line. By selecting an Activity, a Project Planning Lines Budget is selected. Through the Project Planning Lines Budget, both the budgeted and consumed quantity can be determined. * The total budgeted quantity is equal to the quantity in the selected Project Planning Lines Budget. * The consumed quantity is equal to the sum of the billable duration of all time recordings with status *Open* or *Released* belonging to the Project Planning Line Budget plus the sum of the quantities of all Project Planning Lines Billable, which belong to the selected Project Planning Line Budget. When posting Time Recordings, the quantity to be charged (quantity of Project Planning Lines Billable) can be changed. In addition, Project Planning Lines Billable can be created or the quantity increased without posting time recordings. If *no* Activity is selected, the Project Planning Lines Budget cannot be determined. The display is calculated as follows: * The total budgeted quantity is equal to the sum of the quantity of all Project Planning Lines Budget with a Service Billing Type associated to the Project Task. * For the consumed quantity, the sum for the whole Project Task is also formed. Here, the calculation is applied to all Project Planning Lines Budget with a Service Billing Type (Time & Material, Budget, Fixed Price). If there is only one Project Planning Line Budget for the Project Task, the display is identical with or without selected Activity. The progress bar fills the closer the consumed quantity gets to the total quantity. When the total quantity is exceeded, the progress bar is proportionally colored red, if the Project Planning Line Budget has the Service Billing Type Budget or Fixed Price. In case of a 10% overrun, 10% of the bar is displayed in red. From an overrun of 100%, the bar is completely colored red. For the Service Billing Type *Time & Material*, the bar is not colored because the budget is automatically increased when the time recordings are posted. ## Released and posted time recordings Time recordings are approved by the project manager in the **DYCE Project Billing** in Business Central. Once released, time recordings can be posted. Accordingly, time recordings may not be changed after release. They will be *grayed out* to show that they cannot be edited. :::info Simultaneous Edit If a time recording is edited simultaneously in Business Central and **DYCE Time Tracking**, a message about the conflict will be displayed to the user in **DYCE Time Tracking** and the changes will not be saved. A similar message is displayed if the time recording is released in Business Central while the user is editing it in **DYCE Time Tracking**. ::: ## Time zones **DYCE Time Tracking** takes the user's time zone (browser) into account. In Business Central, all Time Recordings are saved in UTC and displayed in the time zone of choice (s. My Settings - Time Zone). All users create their Time Recordings in their own time zone. The time zone is taken from the browser. No setup or conversion is necessary. An appointment from 8:00 to 9:00 in Berlin (UTC+1) will start at different start times in different time zones. In London (UTC), the appointment starts at 7:00 AM and ends at 8:00 AM. In Dubai (UTC+4), the appointment starts at 11:00 AM and ends at 12:00 PM. Users create Time Recordings in their local time zones. All three Time Recordings are displayed in **DYCE Time Tracking** in the local time zones, respectively. In Business Central, the Time Recordings are displayed in the time zone that applies to Business Central. If Business Central works in UTC+1, the three Time Recordings are displayed from 8:00 to 9:00. This allows the user to create their Time Recordings for the appointment in their local time zone without having to calculate an offset. Business Central displays the Time Recordings for the appointment together according to the time zone set in Business Central. --- ## Work Order(Time-tracking) A **work order** is a central document that supports the execution and billing of a specific project, task, or service. For time recording users, a **work order** represents a concrete work instruction. It serves as a hub for communication, planning, execution, and tracking of work packages of all kinds — from internal maintenance tasks to tasks in complex, billable customer projects. The documentation for **[DYCE Project Billing](/docs/pb/welcome.md)** contains a general **[Introduction](/docs/pb/professional-services/introduction.md)** to billing professional services with **DYCE** and detailed information on **[properties of Work Orders](/docs/pb/professional-services/work-order.md#properties)**. This documentation describes how to handle work orders from the perspective of time recording in **DYCE Time Tracking**. ## Billing Work Orders and Sub-Work Orders {#billing-work-order} Customers and planners think in terms of topics — a change request, a project phase, a workshop. They want to see effort, cost, and progress aggregated at that level, and they want to estimate, quote, and approve work at that level too. How the team breaks the topic down internally — into individual tasks or tickets — is a separate question. Work orders support both views with a two-level structure: * The **Billing Work Order** represents the topic. It carries the Customer, the Project, and the master set of budget allocations (Work Order Lines), and it is the level at which time and cost are reported and invoiced. * **Sub-Work Orders** are the individual pieces of work underneath. Each Sub-Work Order rolls its time recordings up to its Billing Work Order, inherits Customer, Project, and Budget Type from the parent, and may only use Work Order Lines that exist on the parent. For straightforward work, a single work order is enough. Sub-Work Orders are worth considering when a topic is split into multiple phases or assigned to different resources, while still being reported and invoiced as one. They are typically created in the source system that already organises work hierarchically — currently Business Central, Jira, or Azure DevOps — and arrive in Connect via synchronisation. ## The Work Order List {#list} The **Work Order List** provides a comprehensive overview of all work orders assigned to the currently logged-in user. It can be accessed via the main menu item **Work Order**. The primary purpose of this page is to give the user quick and direct access to all relevant tasks. The list is therefore always automatically filtered to the work orders assigned to the user. To further narrow down the view, any number of [saved filters](#filters) can be created per user. By default, the following columns are displayed: * **No.:** The unique number of the work order (e.g., WO00092). * **Title:** A short, concise headline. * **Description:** A detailed description of the work to be done. * **Customer:** The external or internal client. * **Project No. and Description:** The parent project of this work order. * **Resource:** The assigned main resource. * **Resource Group:** The assigned resource group. * **Location:** The physical or virtual place where the work is performed. * **Original Estimate:** The estimated time required (in hours or days). * **Completed:** The current status (yes/no). If desired, additional columns can be displayed via the column menu (**…**). The **[Work Order Card](#card)** can be opened either by double-clicking or via the context menu (right-click) on the corresponding row. ### Search The **Search** field allows for a quick search across the following properties: * No. * Resource * Title * Description * Customer * Project No. * Project Description A search restricts the list to the work orders that match the entered search term. Clicking the *x* icon in the search field removes the restriction. ### Define, Save, and Retrieve Filters {#filters} The list can be filtered by one or more properties and criteria by clicking the filter icon (*Y*). The application permanently remembers the active filter criteria and therefore displays the same list each time it is opened. If a set of filtered criteria is needed frequently, it can be saved as a filters using the save icon (💾). The saved criteria can then be easily recalled with a simple click on the filter name. :::tip The color of the filter icon indicates whether filter criteria have been defined. * Gray icon: no filter criteria active * Blue icon: filtering by one or more properties ::: ## Work Order Card {#card} The **Work Order Card** is the central detail view for a single work order. It bundles all relevant **[properties](/docs/pb/professional-services/work-order.md#properties)** from the areas of description, assignment, commercial details, and planning in one place. This view is typically opened when a user double-clicks an entry in the **Work Order List** or navigates to a linked work order from other parts of the application, such as the "Tasks" page or the context menu of a time entry. ### General Structure The **Work Order Card** is clearly divided into three main areas: the header, the tabs, and a dynamic sidebar. * The **header** displays the most important identifying features of the work order: the work order number, the title, and brief info on the customer, type, and status. * The **tabs** group the properties into four areas: General, Invoicing, Planning, and Details. * The **right sidebar** contains a dynamic dashboard that summarizes the most important key figures of the work order. The content of this bar changes slightly depending on the selected tab. ### General Tab {#general} This tab contains the basic descriptive information of the work order necessary to understand the task. The following fields can be edited by the time recording user: * **Title, Description, and Resolution:** Define what the work order is about. * **Internal Note:** Text field for additional, non-public information. * **Type:** A classification of the work type (e.g., Story, Bug, Task). The list of possible values is maintained centrally in the respective source system (e.g., Business Central, Jira, Azure DevOps). * **Completed (Toggle):** Specifies whether the work order is considered done. The status in the header area (*Open / Completed*) is directly derived from this toggle. * **Blocked (Toggle):** Can be used to block a work order from further time recording. For more information, see the chapter [properties of a work order](/docs/pb/professional-services/work-order.md#properties). ### Invoicing Tab {#invoicing} All information relevant for invoicing and budgeting is configured and viewed here. The tab is divided into four sections: **Customer & Project**, **Budget**, **Work Order Estimates**, and **Time Recordings**. For a time recording user the tab is mostly read-only — the fields are populated by the planner and the integrations (Jira, Azure DevOps, Business Central). The **Remaining Estimate** is the exception and can be updated to give the planner feedback on progress. This section explains what those values mean. #### Customer & Project The basic assignment of the work order. The Customer and Project drive everything that follows: which planning lines can be picked, which activity rates apply, and where the invoice ends up. :::info On a Sub-Work Order the two fields are inherited from the parent Billing Work Order and can not be changed, so every Sub-Work Order under the same Billing Work Order posts against the same customer and project. ::: See [Customer and Project Rules](/docs/pb/professional-services/work-order-business-rules.md#change-customer-project) for the full reasoning. #### Budget * **Billing Work Order:** Read-only reference to the [Billing Work Order](#billing-work-order) on which the time will be invoiced. * **Budget Type:** Either **Open** or **Project**, set by the planner. The setting determines how strictly your time recordings are tied to the work order's planning lines — see the [Budget Type](/docs/pb/professional-services/work-order.md#properties) chapter for what each option means. * **Work Order Lines:** A grid showing which Project Planning Lines are budgeted for this work order — each row is one allocation. Columns: * **Project Task No.**, **Project Task Description**, and **Project Planning Line Description** — together these identify the Project Task and Project Planning Line the Work Order Line points at. This *is* the reference to the budget; time recordings booked against the line consume that planning line's budget. * **Activity** — optional. If the planner sets one, it serves as the default activity for time recordings against this line; the user can always change it on the time recording. * **Service Billing Type** — *Time & Material*, *Budget*, or *Fixed Price*; a dollar-icon next to the activity shows the billable status * **Reserved Qty.** — optional; how much of the planning line's budget is reserved exclusively for this work order. Treat it as the time-recording budget for the task. If it is 0, no exclusive reservation is in place and the whole planning-line budget is available to draw from. * **Qty. Available to Reserve** — what is left of the planning-line budget after current reservations Quantities under 8 hours are shown in hours; 8 hours or more are shown in days (1 day = 8 hours). #### Work Order Estimates * **Original Estimate:** The initially estimated effort. * **Remaining Estimate:** Can be updated to track the remaining effort and give feedback to the project manager. #### Time Recordings Shows a list of all time entries booked to this work order. All users can see all entries, but each user can only edit their own time entries. Editing is done via double-click or the context menu. Creating new entries is not possible in this view. ### Planning Tab {#planning} This tab is for operational planning and resource assignment. * **Planning Fields:** Shows the primarily assigned resource, a resource group, and optionally a location, sprint, or area. The primary resource and resource group cannot be changed by the time recording user. * **Events:** "Events" are specific appointments or scheduled work blocks. Users can plan their work on the work order in detail for one or more resources here, including specific start and end times. New events can be created via **⊕ NEW**, and existing ones can be edited or deleted. For more information, see the chapter [properties of a work order](/docs/pb/professional-services/work-order.md#properties). ### Details Tab {#details} This tab contains links, references, and historical data that are for informational purposes only and generally cannot be edited. * **External Link:** Links the work order to the original item in an external system (e.g., a Jira issue). * **Billing Work Order:** Refers to a parent work order if this is a subtask. * **Link:** A direct link to this work order card. ### Sidebar The **sidebar** provides a quick overview of the work order's status: * **Planning:** * Scheduled: A status indicator (visualized by a green checkmark next to the resource) shows if the work order is scheduled. The checkmark appears as soon as at least one [Event](#planning) (planned work block) exists in the **Planning** tab. * Resource: Shows the primarily assigned resource. * **Time Recording:** * Estimated: The originally estimated effort in hours (this value comes from the **Original Estimate** field in the [Invoicing](#invoicing) tab). * Actual: The sum of all hours actually recorded for this work order, regardless of the recording resource. * **Budget:** * Budget Type: The budget type selected on the [Invoicing](#invoicing) tab. * Quantity: The budget set for the work order (e.g., in days), derived from the linked Project Planning Line (type *Budget*) (appears only if a Project Planning Line has been selected). * Actual: The portion of the budget already consumed (appears only if a Project Planning Line has been selected). ## Work Order Events in the Task List A **work order event** is a specifically scheduled block of work for a particular resource at a set time. While the work order describes the task itself, the event defines the exact time of execution. As soon as a planner creates an event for a resource, it automatically appears in the **[Tasks](/docs/web/tt/time-tracking/tasks.md)** view of the respective user. These entries serve as a personal daily or weekly plan, showing which tasks are to be completed and when. Each event in the task list offers a quick time entry function. By clicking on **New Time Recording**, a time entry is created that is already fully pre-populated with data from the work order and the event: * **Date, Start, and End Time** are taken directly from the scheduled event. * **Customer, Project, Project Task, and Activity** are taken from the billing details of the linked work order. * The **Description** can be pre-filled with the title of the work order. This eliminates the manual search for the correct project data, significantly speeds up time tracking, and reduces the likelihood of errors. The user only needs to confirm or slightly adjust the recorded time. ## Restrictions for Time Recording Users Users of Time Tracking are subject to certain restrictions to ensure the consistency of planning and budget data. **Disallowed Actions:** * Work orders cannot be deleted. * Commercial and budget-relevant fields cannot be changed. This includes: * Customer * Project * Budget Type * Original Estimate * The **Work Order Lines** grid is read-only: lines cannot be created, selected, edited (Activity, Reserved Qty.), or deleted. * Planning-relevant fields such as the primary resource or resource group cannot be changed. **Allowed Actions:** Time recording users can edit all fields relevant to the description and status of their own work: * Title * Description * Internal Note * Resolution * Type * Completed (Status) * Remaining Estimate * Area * Sprint * Manage Events (create, edit, delete) --- ## Calendar(Planning) # Planning Calendar The **Planning Calendar** is a visual scheduling tool for project managers and resource planners that want to plan work orders on resources. It provides an interactive timeline view that shows at a glance which resources are assigned to which work orders and when their work is scheduled. The primary purpose of the calendar is to manage resource utilization, identify bottlenecks, account for absences, and schedule work efficiently. ## Overview The calendar view is divided into several interactive areas that allow for intuitive drag-and-drop planning. ### Timeline The main area of the calendar is a list of resources on the left and the timeline on the right. Each row represents a single **Resource**. In addition to the resource's name, the list includes columns for the **Resource** **Group** (e.g., "Consultants", "Developers"), **Skills**, and planned **Effort / Capacity** to aid planners in making assignments. The columns on the timeline represent time, typically in hours for a selected day, depending on the zoom level. The timeline visualizes three types of entries: * **Work Order Events:** These are the colored blocks representing a specific **Work Order** assigned to a resource for a defined period. These events are the exact same ones that are created and managed in the `PLANNING` tab of the [Work Order Card](/docs/web/prp/planning/work-order.md#planning). * **Unavailable Time:** Blocks with a grey background pattern indicate when a resource is unavailable. This includes scheduled **Breaks** (according to the [work hour template](/docs/pb/masterdata/resource.md)) as well as **Absences** (e.g., due to vacation or illness) which come directly from the [Absence module](/docs/web/tt/time-tracking/absences.md) of DYCE Time Tracking. * **Exchange Events:** Appointments from users' Outlook calendars are optionally displayed to provide additional context for planning and help avoid scheduling conflicts. :::info Exchange integration Exchange events become available if the feature is enabled by an administrator and the necessary permissions to the Exchange calendars have been granted. Refer to the setup instructions in the [Setting up DYCE Connect](/docs/web/administration/setup-web.md#exchange) documentation for more details. ::: ### Work Order Panel On the right side of the screen, the **Work Orders panel** can be expanded or collapsed by clicking on the blue arrow button. This list functions as the backlog, typically containing a filtered list of all unscheduled work orders (depending on the active user-configurable filters). The panel’s purpose is to display a list of work orders that the planner can assign to resources in the timeline. Filtering works in the same way as in the [Work Order List](/docs/web/prp/planning/work-order.md#list) and can be customized by each user. The list can be searched and sorted by various criteria, such as **Customer**, **Project**, **Resource Group**, or **Status**. :::tip Show only unscheduled work orders Set a filter on the field **Scheduled** to *No* to display only unscheduled work orders in the list. This helps planners focus on the tasks that still need to be assigned. ::: ### Filtering and Navigation The Controls at the top of the calendar customize the view: * **Date Navigation:** Arrows to move forward and backward, as well as a "Today" button to jump to the current day. * **Zoom level:** Controls the timeline's scale (e.g., showing more or fewer hours or days). * **Resource Filters:** Powerful filters to narrow down the display to a specific **resource group** (e.g., "Developers," "Consultants") or resources with specific skills. * **Show Exchange Events Toggle:** A switch that allows planners to show or hide the Outlook appointments for all displayed resources. This helps to declutter the view when not needed. ## Interactions and Workflows The calendar is designed for dynamic planning. The most common actions are: * **Scheduling a Work Order:** A planner drags a work order from the backlog via **drag and drop** directly onto the timeline of an available resource. This creates a new **event** for this work order, establishing the link between the resource, work package, and time. * **Adjusting Plans:** * **Rescheduling:** An existing event can be easily moved along the timeline to change its timing or dragged to another resource's row to change the assignment. * **Adjusting Duration:** The length of the event block can be intuitively changed by dragging its start or end to extend or shorten the planned duration. * **Viewing Details:** A **double-click** on an event in the calendar opens the detailed [Work Order Card](/docs/web/prp/planning/work-order.md#card), where all information can be viewed and edited. * **Conflict Detection:** The system provides visual support during planning. If a planner attempts to place an event in a period where the resource is already blocked by an **Absence**, **Break**, or **Exchange Event**, this is indicated by an orange color highlighting. ## Integration into the DYCE Workflow The Planning Calendar is seamlessly integrated into the DYCE application landscape: * **Connection to the Work Order Card:** All "Events" created or modified in the calendar are reflected in real-time in the `PLANNING` tab of the corresponding Work Order Card, and vice versa. * **Connection to DYCE Time Tracking:** The events scheduled here appear as entries on the respective employee's personal **Tasks and Calendar page** in DYCE Time Tracking. This communicates the actionable tasks to the executing employee. ## Exchange Events: Pre-requisites and Troubleshooting {#exchange} For Exchange events to be displayed on the Planning Calendar, a connection must be established between a DYCE resource and a user's Exchange mailbox. The mapping between resources and Exchange mailboxes is configured in the **DYCE User Setup** page within the administration area. An administrator links a DYCE user to a specific resource, which establishes the link to an Exchange account. Refer to the setup instructions in the [Setting up DYCE Connect](/docs/web/administration/setup-web.md#exchange) documentation for more details. **Error Handling:** If the system fails to load Exchange events for a specific resource, a small **red warning icon** will appear next to the resource's name in the timeline. Hovering over this icon will display a tooltip explaining the cause of the problem. Common issues include: * Calendar not shared: The administrator has not granted access to the user's calendar. * Resource assigned to multiple users: In the user setup, multiple users are linked to the same resource, but a unique assignment is required. * Resource not assigned to any user: The resource has no corresponding user assigned in the user setup. * User has no calendar: The user does not have a calendar in Exchange Online. * Could not load calendar / Could not load appointments: The user's Exchange calendar is not accessible. * Administrator has not granted permission: The administrator has not completed the required setup steps. * Mailbox inactive: The user's Exchange mailbox is no longer active, e.g., due to license issues. --- ## People This page shows all the resources and their utilization. The main part of the screen is divided into the following three areas: ## Action bar The user can filter and search for people here and specify the maximum number of resources to be loaded. Tentative projects can optionally be taken into account in the workload and the workload display can be switched. The date range of the workload (see below) can be scrolled through, taking into account the zoom level. The page can also be refreshed here. ## Resource list The Resource List on the left displays the names, resource group, and skills of the resources. ## Utilization The availability or workload (depending on the zoom level) is displayed for each person. For the selection *Available*, the fine red line describes the person's capacity per period, with absences and public holidays already deducted. Below the red line, the green area shows tasks for which the person is already planned. If the planned tasks for a period exceed the capacity (and therefore also the red line), the area is displayed in red. When you move the cursor over an area, further details such as the number of planned time units (depending on the zoom level) are displayed. If the display is to show the workload instead of the availability, the view in the action bar must be switched to *Utilization*. The number of planned time units (depending on the zoom level) is now displayed for each person, combined with the same color indication (see above). Absences appear in gray. In addition, the planned tasks for each person can be expanded using the triangular arrow menu. Persons without planned tasks are marked with a dot instead of the arrow menu. :::tip Maximize display area The sidebar can be minimized using the arrow symbol at the top to enlarge the display area. The minimized sidebar only displays the icons. It can be expanded again in the same way. ::: --- ## Project Card The **Project Card** is the central page for creating and managing a project plan. It is opened by either clicking on a existing project in the [Projects List](/docs/web/prp/planning/projects.md) or by creating a new project with the **NEW** action. The card is divided into several tabs * **PLAN**: The project plan with tasks, Gantt chart and project resources * **PEOPLE**: The project team with assigned tasks and utilization * **DETAILS**: The project details with general information, budgeting and scheduling ## Plan Tab The first tab in the project card contains the **project plan**. It provides a flexible representation of the project tasks (work breakdown structure) in the form of a *Gantt chart* and the *project resources* that are assigned to the project. * **Tasks in the project plan** This is a hierarchical breakdown of the project scope into smaller and more manageable components. It shows the relationship and dependencies between the project elements (e.g. tasks, milestones and resources). It helps to define the individual tasks in the project, allocate resources and estimate the duration and budget of the project. * **Gantt chart** The Gantt chart graphically depicts the project schedule. It shows the start and end date and therefore the duration of the tasks as well as the dependencies and restrictions between them. It helps to visualize the project schedule and monitor progress. * **Project resources** The project resources represent the people working on the project. People are assigned to tasks. Both capacity and qualifications play a role here. The tasks and the Gantt chart are displayed next to each other. By activating the **Show resources** button, the project resources including their utilization also appear in the lower area of the window. The separators between the respective areas (project tasks and Gantt chart and also the project resources) can be moved individually using the cursor. :::tip Quickly customize display A double arrow (\<>) appears on the vertical separators between tasks and the Gantt chart or the project resources and their utilization when the cursor is moved over them. When you click on one of the two arrows, the corresponding area is maximized and the button is then displayed at the edge of the screen. If you click on the arrow again (in the other direction), the previous display is restored. ::: ### New Task The action **NEW** (*Alt+N*) creates a new task in the project plan. The consecutive number and the level of the work breakdown structure are assigned automatically. This is also the case if the sorting of the rows is adjusted manually by moving (holding down at the start of the row), i.e. the number and level are updated. Right-click on a process to open a selection for editing (copy, delete, indent, etc.). Alternatively, a new line can also be created using the *PLUS* button between **WBS** and **Mode**. This button appears when you move the cursor over the position. The **Mode** gets its initial value from the preset in the [details tab](#details) and can be changed by double-clicking in the field. There are three different modes (*Fixed duration*, *Manual* and *Auto*) to choose from (details [see below](#scheduling-mode)). :::info Default setting The settings in the **Mode** field are a summary of several planning parameters that can also be set manually for each task via the `Advanced` tab ([see below](#scheduling-mode)). The following default settings are made in detail: * **Scheduled with fixed duration** * Scheduling mode: Fixed duration * Effort driven: Yes * Manually scheduled: No * Consequence: The duration of the task remains unchanged in any case. The project plan automatically calculates the start and end time of the task based on its position in the plan and the dependencies on other tasks. * **Manually scheduled** * Scheduling mode: Fixed duration * Effort driven: Yes * Manually scheduled: Yes * Consequence: The duration of the task remains unchanged in any case. In addition, the set start and end times are not calculated. This mode is suitable, for example, for milestones that are to be fixed to a point in time. * **Auto scheduled** * Scheduling mode: Fixed duration * Effort driven: No * Manually scheduled: No * Consequence: The duration, start and end parameters are calculated by the project plan. The start and end time of the task is calculated based on its position in the plan and the dependencies to other activities. The duration is calculated based on the effort and the assigned resource capacity. The Scheduling mode *Fixed duration* is therefore always preset for each **Mode**. ::: The **Name** is freely assigned by the user. A *normal* task is represented by a *dot* in front of the name. However, it is also possible to *indent* one or more tasks via the context menu (right-click). Instead of the dot, the superordinate task receives an arrow to expand the associated tasks and thus becomes a summary task. Automatically planned tasks are aligned with their summary task. However, this differs from a mandatory chronological sequence (**Predecessor**, see below). The **Effort** describes the effort or time required for this task. The **Duration** represents the period of time in which the effort is made. Depending on the scheduling mode, it is possible that one or both fields will be recalculated at a later point in time - e.g. when a resource is added. **Start** (and **End** - hidden by default) express the duration of the task as a date range. The **[Assigned Resource](#project-resources)** field shows the abbreviations of the resources that are intended for this task. Additional resources can also be added via the lookup in the field. The **Predecessor** indicates which task in the project plan must precede the processing. The selection can be made via the selection menu or by entering the work breakdown structure number (WBS number). Normally, end-to-start is assumed, i.e. the previous task must be completed before the next one is started. In principle, however, other types of dependencies are also possible. The **Skill** is used to define whether and, if so, which skills are required to complete the task. The **Budget** and **Remaining Budget** fields are related. If a Business Central Project is assigned in the [details tab](#details), budgets can be selected and allocated for collective and individual tasks in the form of Project Tasks and Project Planning lines. The remaining budget is then calculated based on the time recordings made. **Recorded %** calculates the percentage of Time Recordings for this specific task in relation to the total effort for this task (**Effort** column). ### Edit Task Each task has a context menu which can be called up using the right mouse button. The **Edit** action opens a new window with several tabs. The `General` tab contains most of the information that is also displayed in the project task. The `Predecessor`, `Successor` and `Resources` tabs allow detailed fine-tuning such as types of predecessor and successor relationships and delays between tasks. In the `Advanced` tab, detailed specifications can be made that control the effects of the activity on the calculation of the project plan. ### Scheduling mode {#scheduling-mode} An activity can be planned either *automatically* or *manually*. This is defined by the *Manually planned* indicator. Manually planned operations are not taken into account by automatic rescheduling and must therefore be adjusted manually by the user. Tasks to be automatically planned are updated with regard to their start and end dates and based on their possible restrictions, links and position in the project plan. This means that the start date and end date may be recalculated. The scheduling mode specifies how the properties of the task depend on each other. It determines which properties are fixed (specified by the user) and which are to be calculated. Four basic scheduling modes are available: * Normal * Fixed Duration * Fixed Units * Fixed Effort In addition, there is the *Effort driven* indicator, with which the effort of the task can be fixed. If it is set, it instructs the task to retain its effort and recalculate other properties instead. :::info Custom scheduling mode By changing one of the fields in the `Advanced` tab, the **Mode** is set to *empty*. This indicates that manual changes have been made to the way the task is calculated. ::: * **Normal** In *Normal* mode, the task is scheduled based on the information about its start/end date. The effort is not calculated in this mode. This mode is always used for collective tasks. The *Effort driven* indicator is not used in this mode. * **Fixed Duration** The *Fixed Duration* mode means that the task has a fixed start and end date and a fixed duration, but its effort is calculated dynamically based on the allocated resources. A typical example of such a task is a *meeting*. Meetings usually have predefined start and end dates, and the more people attend the meeting, the more effort is spent on the event. If the duration of such an event increases, its effort also increases. Changes to the effort of such an task lead to a recalculation of the allocated units and vice versa (changes to the allocated units lead to a recalculation of the effort). Activating *Effort driven* for an activity changes this behavior and forces the activity to recalculate its assigned units whenever the activity changes its duration or effort. ***Note***: The calculations in this mode only work if at least one resource is assigned to the task. * **Fixed Units** The *Fixed Units* mode means that the task has permanently assigned units and a fixed duration *or* a fixed effort. Changes to the effort of such a task lead to a recalculation of the duration and vice versa (a change to the duration leads to a recalculation of the effort). Changes to the assigned units of such an operation lead to a recalculation of the effort and duration if the *Effort driven* indicator is activated. ***Note***: The calculations in this mode only work if at least one resource is assigned to the task. * **Fixed Effort** The *Fixed Effort* mode means that the task has a fixed effort and a fixed calculated duration. The more resources assigned to the task, the shorter the duration. It is typically used for tasks that can be easily scaled and processed by several people. An example of a task of this type is *painting walls* - several painters will complete this more quickly. Activating the *Effort driven* flag makes no sense in this mode. ***Note***: The calculations in this mode only work if at least one resource is assigned to the task. ### Gantt chart In the Gantt chart, the chronological sequence of tasks is displayed graphically on a time axis. The zoom level can be changed using the familiar control elements. Collective tasks visually span their subordinate individual tasks. :::tip Milestones Milestones are tasks without a duration. They are displayed as a diamond. A milestone is initially created like a normal task and can have predecessors and successors. It becomes a milestone when its duration is set to 0. Alternatively, it can be converted to a milestone via the context menu (right-click). In this case, the duration is set to 0, but the effort remains the same. ::: Although it is not possible to add new activities within the Gantt chart, the **NEW** action creates a new task in the project plan, which is then immediately displayed. Depending on the scheduling mode, the user can change the length of a task at the start or end of the element. This change is immediately applied to the duration of the task. If a connecting line is also drawn with the cursor between the end of a task and the start of another task, this creates a dependency between the two, which is also reflected in the **Predecessor** field of the work breakdown structure. The progress of time recorded against the task's effort (**Recorded %**) is visualized as a darker shade filling the task's bar in the Gantt chart. ### Project resources {#project-resources} Once the project plan has been created, the project team must be put together and the people for processing individual tasks must then be planned. By activating the **Show Resources** button, a new area is displayed at the bottom of the page. To put together the project team, resources must be added to the project here. When the **ADD** action is called up, a new window opens showing all the resources of the Business Central company. A distinction can be made here between *real* resources and [placeholders](/docs/pb/masterdata/resource.md#placeholder). :::info Placeholder In **DYCE Project Billing**, resources can be marked as placeholders. In contrast to persons (blue symbol), placeholders are displayed with a green symbol. In principle, they behave like normal resources. However, assigning a placeholder to a task does not reduce its required capacity. ::: Persons and placeholders can be filtered using a full text search. This also includes skills. To transfer to the project team, the relevant data records are selected via the selection field and the page is closed with the **Add** action. ### Assign resources One or more people can be assigned to each task. The assignment is made either by selection via the **Assigned Resource** field in the project plan or using the mouse via drag & drop. To determine a suitable resource from the project team for a task, click on the **Skill** in the project plan to use this as a filter for the resources. If there is no resource in the team that matches the required qualification, it must first be [determined and added](#project-resources). Placeholders can also be used first. Before assigning a resource to a task, the capacity should first be checked. The resource can then be dragged to the task with the mouse and dropped there (drag & drop) or selected in the project plan via the **Assigned Resource** field. The effect on the capacity is immediately recalculated and displayed. Placeholders are always used if no specific person can yet be named or planned for a task. It is advisable to replace the placeholders with suitable persons as the project planning progresses. Ideally, placeholders should be replaced in the `PERSONS` tab. On this page, the placeholders are displayed in the upper area (if **Show Placeholders** is activated) and the real persons are displayed in the lower area. At the same time, the right-hand side of the page shows for each placeholder which tasks are currently planned for the placeholder. When replacing a placeholder with a real person, the filter for a possible skill can be used again. The easiest way to replace is to move the task from the placeholder to the person on the right-hand side of the page using the mouse (drag & drop). Placeholders without planned tasks can be deleted via the context menu. ### Assign Budgets Budgets from Business Central can be linked anywhere in the project plan. The budgets correspond to the Project Planning lines. The procedure therefore roughly depends on the structure in which the Project Planning lines are created. If, for example, these represent rather rough budgets, it makes sense to assign these budgets to the collective tasks. The time recordings for all tasks below the summary tasks are automatically linked to the parent budget. The budget is assigned by making a selection in the **Budget** field. The values in the **Remaining Budget** and **Recorded %** fields are displayed or updated at the moment the budget is assigned. During the course of the project, these values are continuously updated by [Time Recordings](#time-recordings) of the project team members. ### Time Recordings {#time-recordings} In **DYCE Time Tracking**, the page [Tasks](/docs/web/tt/time-tracking/tasks.md) shows all tasks for which the logged-in user is scheduled. The search field can be used to restrict the display accordingly. A new time recording can be started using the button of the same name. The time recording mask opens, in which the **Customer**, **Project** and **Project task** fields are already predefined. In addition to the description and duration, only the **Activity** needs to be selected. The time entered is immediately displayed as progress in the project plan under the related budget. The remaining budget and the progress (**Recorded %**) are updated. At the same time, the (quantitative) progress is also shown in the Gantt chart as a dark-colored area of the bar. ## People Tab The second tab in the project card contains the **people** assigned to the project. This page shows the same project resources as in the `PLAN` tab, but with a different focus. It offers more screen estate for the project resources and their utilization and allows the assignment of resource to placeholders. **Show placeholders** toggles the display of the placeholders section in the upper area of the page. The real persons are displayed in the lower area. If a placeholder is selected, all tasks that are currently planned for this placeholder are displayed on the right side of the page. This makes it easy to see which tasks still need to be reassigned when replacing a placeholder with a real person. ### Release resource bottlenecks There are several ways to resolve conflicts or resource bottlenecks. Firstly, additional people can be assigned to a task. This distributes the total workload across all assigned persons. Alternatively, it is possible to extend the task. This distributes the effort over a longer period and thus reduces the effort per person and time unit. A detailed description can be found on the page [People](/docs/web/prp/planning/people.md). Similar to the tasks in the project plan, people with only one planned task are displayed with a dot in front of their name. If a person is planned for several tasks, this is indicated by an arrow in front of the name. The tasks can be expanded by clicking on the arrow. This allows you to determine which projects or tasks the person is planned for, where the workload comes from and what needs to be done to release the conflict. The project associated with a task can be opened by clicking on the respective task. ## Details Tab {#details} The third tab in the project card contains the project's **details**. This is where the masterdata for a project is recorded and the connection to a project in Business Central is established. #### General Section In addition to the **Name** or title for the project, an extended **Description** can be stored. In addition, a **Logo** can be assigned to the project for better visual differentiation. In the **Customer** field, the customer can be selected from Business Central using the lookup. The same applies to the **Project (Business Central)** field. The related Business Central project is stored here, from which the budgets can be transferred. :::info Independent project planning With **DYCE Project & Resource Planning** it is possible to plan projects without first having to create a project in Business Central. The link to a project in Business Central can also be created subsequently. Even without a project from Business Central, the project plan can be created and the workload of the people can be calculated and any bottlenecks identified. ::: The **Status** field offers the option of assigning a status to the project. This field can be used for filtering in the [Project list](/docs/web/prp/planning/projects.md). The **Tentative** toggle flags a project as tentative. Tentative projects are listed with a *question mark* (*?*) symbol in the project list. When viewing the workload of people, tentative projects can be optionally included or excluded. :::tip What-if simulation The **Tentative** button can be used to carry out a form of a what-if simulation, e.g. by not including *tentative* projects in the capacity utilization calculation, but removing the indicator for individual projects if required. ::: #### Scheduling Section The project duration is determined based on the **start date** and **end date**. The **Scheduling Mode** specifies the default mode for new tasks. The following options are available: * Scheduled with fixed duration * Manually scheduled * Auto scheduled For further details on the planning mode, please refer to the chapter [Scheduling Mode](#scheduling-mode). --- ## Projects(Planning) The **Projects** page is the homepage of the **Planning** section. It provides an overview of the existing projects and their chronological order. ## Page Overview The main part of the screen is divided into the following three areas: **Action bar**: The user can filter and search for projects and create new projects here. The date range of the timeline can be scrolled through, taking into account the zoom level. The print dialog can export the project list and the timeline. The whole page can also be refreshed here. **Project list**: The overview shows the names of the projects including logo, customer and project details. Projects can be edited, copied or deleted via the context menu. **Timeline**: The project period (depending on the zoom level) is displayed for each project. :::tip Maximize display area The sidebar can be minimized using the arrow symbol at the top to enlarge the display area. The minimized sidebar only displays the icons. It can be expanded again in the same way. ::: ### Navigation / Action bar The **Filter** allows you to restrict the project list using predefined criteria. For the selection *Customer*, one or more customers can be selected from the entirety of all customers. The same applies to the *Status*, whereby this can be set in the respective [project card](/docs/web/prp/planning/project-card.md#details). For *Favorite* and *Tentative* there is the option to include or exclude them. Both criteria are also displayed in the project list in the form of an icon. The *Tentative* indicator can also be set in the [project card](/docs/web/prp/planning/project-card.md#details). All set filters are displayed to the right of the button. **Search** enables a free text search within the projects. A new project can be created via **NEW**, which will open the [project card](/docs/web/prp/planning/project-card.md). Further on the right-hand side, the arrow buttons to the right and left of **Today** can be used to scroll through the date range displayed below, depending on the zoom level (+/-) set, which can be adjusted using the magnifying glass symbols. Next to this are the **Print** and **Refresh page** functions. ### Project list The projects are displayed here, taking into account the set filters. For visual differentiation, the optional project logos are displayed to the left of the project name. The name of the customer and the project period are displayed below. Click on the project to open the project plan. A *question mark* (*?*) indicates that this project has been marked as [Tentative](/docs/web/prp/planning/project-card.md#details). A *star* marks it as a *Favorite*. Both criteria can be used to filter the project list. Via the context menu, the selection *Edit* opens the [Project card](/docs/web/prp/planning/project-card.md). The selection *Copy* creates a copy of the project, *Delete* removes it. :::tip Templates for projects A *template project* can be created for projects with a similar structure, which can then be used to quickly create project plans for similar customer projects. This *template project* can be copied if required. ::: ### Timeline To the right of the projects, the temporal extent of the projects (depending on the zoom level) is displayed. --- ## Work Order(Planning) A **work order** is a central document that supports the execution and billing of a specific project, task, or service. It serves as a focal point for the communication, planning, execution, and tracking of work packages of all kinds – from internal maintenance tasks to tasks in complex, billable customer projects. The documentation for **[DYCE Project Billing](/docs/pb/welcome.md)** contains a general **[Introduction](/docs/pb/professional-services/introduction.md)** to billing professional services with **DYCE** and detailed information on **[properties of Work Orders](/docs/pb/professional-services/work-order.md#properties)**. **Work orders** play a role in several DYCE apps. This documentation describes the planning functionality within **Project & Resource Planning** and establishes cross-connections to **Time Tracking** and **Project Billing**. ## Planning Services with Work Orders As mentioned above, work orders cover several aspects necessary for the delivery and billing of services. **Project & Resource Planning** enables the creation and editing of work orders, the selection of existing project budgets for time recording, and the scheduling of services via **Work Order Events**. ## Billing Work Orders and Sub-Work Orders {#billing-work-order} Customers and planners think in terms of topics — a change request, a project phase, a workshop. They want to see effort, cost, and progress aggregated at that level, and they want to estimate, quote, and approve work at that level too. How the team breaks the topic down internally — into individual tasks or tickets — is a separate question. Work orders support both views with a two-level structure: * The **Billing Work Order** represents the topic. It carries the Customer, the Project, and the master set of budget allocations (Work Order Lines), and it is the level at which time and cost are reported and invoiced. * **Sub-Work Orders** are the individual pieces of work underneath. Each Sub-Work Order rolls its time recordings up to its Billing Work Order, inherits Customer, Project, and Budget Type from the parent, and may only use Work Order Lines that exist on the parent. For straightforward work, a single work order is enough. Sub-Work Orders are worth considering when a topic is split into multiple phases or assigned to different resources, while still being reported and invoiced as one. They are typically created in the source system that already organises work hierarchically — currently Business Central, Jira, or Azure DevOps — and arrive in Connect via synchronisation. ## Work Order List {#list} The **Work Order List** provides a comprehensive overview of all work orders in **DYCE**. It can be accessed via the main menu item **Work Order**. The primary purpose of this page is to give the user quick and direct access to all relevant work orders. To narrow down the view, any number of [saved filters](#filters) can be created per user. By default, the following columns are displayed: * **No.:** The unique number of the work order (e.g., WO00092). * **Title:** A short, concise headline. * **Description:** A detailed description of the work to be done. * **Customer:** The external or internal client. * **Project No. and Description:** The parent project of this work order. * **Resource:** The assigned main resource. * **Resource Group:** The assigned resource group. * **Location:** The physical or virtual place where the work is performed. * **Original Estimate:** The estimated time required (in hours or days). * **Completed:** The current status (yes/no). If desired, additional columns can be displayed via the column menu (**…**). The [Work Order Card](#card) can be opened either by double-clicking or via the context menu (right-click) on the corresponding row. New work orders can be created using the **⊕ NEW** function. This function starts a wizard that guides you through the most important properties of a work order in three steps. One or more selected work orders can be deleted using the trash can symbol (**🗑**). ### Search The **Search field** allows for a quick search across the following properties: * No. * Resource * Title * Description * Customer * Project No. * Project Description A search limits the list to the work orders that match the entered search term. Clicking the *x* symbol in the search field removes the filter. ### Filtering and Saving Views {#filters} The list can be filtered by one or more properties and criteria by clicking the filter symbol (*Y*). The list permanently remembers the active filter criteria and therefore displays the same list each time it is opened. If a set of filtered criteria is needed frequently, it can be saved as a filters using the save symbol (💾). The saved criteria can then be easily recalled with a simple click on the filter name. :::tip The color of the filter symbol indicates whether filter criteria have been defined. * Gray symbol: no filter criteria active * Blue symbol: filtered by one or more properties ::: ## Work Order Card {#card} The **Work Order Card** is the central detail view for a single work order. It bundles all relevant [properties](/docs/pb/professional-services/work-order.md#properties) from the areas of description, assignment, commercial details, billing, and planning in one place. This view is typically opened when a user double-clicks an entry in the **Work Order List** or navigates to a linked work order from other parts of the application, such as the **Tasks** page or the context menu of a Time Recording. ### General Structure The **Work Order Card** is clearly structured into three main areas: the header area, the tabs, and a dynamic sidebar. * The **header area** displays the most important identification features of the work order: the work order number, the title, and brief information about the customer, type, and status. * The **tabs** group the properties into four areas: General, Invoicing, Planning, and Details. * The **right sidebar** contains a dynamic dashboard that summarizes the most important key figures of the work order. The content of this bar adapts slightly depending on the selected tab. ### General Tab {#general} This tab contains the basic descriptive information of the work order. * **Title, Description, and Solution:** Define what the work order is about. * **Internal Note:** Text field for additional, non-public information. * **Type:** A classification of the work type (e.g., Story, Bug, Task). The list of possible values is maintained centrally in the respective source system (e.g., Business Central, Jira, Azure DevOps). * **Completed (toggle):** Determines if the work order is considered done. The status in the header area (*Open / Completed*) is directly derived from this toggle. * **Locked (toggle):** Can be used to lock a work order for further time recording. For more information, see the chapter [properties of a work order](/docs/pb/professional-services/work-order.md#properties). ### Invoicing Tab {#invoicing} All information relevant for invoicing and budgeting is configured and viewed here. The tab is divided into four sections: **Customer & Project**, **Budget**, **Work Order Estimates**, and (on an existing work order) **Time Recordings**. #### Customer & Project The basic assignment of the work order. The Customer and Project drive everything that follows: which planning lines can be picked, which activity rates apply, and where the invoice ends up. :::info On a Sub-Work Order the two fields are inherited from the parent Billing Work Order and can not be changed, so every Sub-Work Order under the same Billing Work Order posts against the same customer and project. ::: On a Billing Work Order with **Budget Type = Project**, Customer and Project lock as soon as the first Work Order Line is added, because the lines already bind the work order to a specific project budget. See [Customer and Project Rules](/docs/pb/professional-services/work-order-business-rules.md#change-customer-project) for the full reasoning. #### Budget * **Billing Work Order:** Read-only reference to the [Billing Work Order](#billing-work-order) on which the time is invoiced. If it points to this work order itself, this is a Billing Work Order; otherwise it is a Sub-Work Order. * **Budget Type:** Either **Open** or **Project**. On a Sub-Work Order the field is disabled because the Budget Type is inherited from the Billing Work Order. The setting controls how strictly time recordings have to match the work order's planning lines — see the [Budget Type](/docs/pb/professional-services/work-order.md#properties) chapter for what each option means. * **Work Order Lines:** A grid in which each row links the work order to a Project Planning Line — i.e. to a single budget allocation. Multiple lines per work order let one work order draw from several planning lines. Columns: * **Project Task No.**, **Project Task Description**, and **Project Planning Line Description** — together these identify the Project Task and Project Planning Line the Work Order Line points at. This *is* the reference to the budget; time recordings booked against the line consume that planning line's budget. * **Activity** — optional. If set here, it serves as the default activity for time recordings against this line; the user can always change it on the time recording. * **Service Billing Type** — *Time & Material*, *Budget*, or *Fixed Price*; a dollar-icon next to the activity shows the billable status * **Reserved Qty.** — optional; how much of the planning line's budget is reserved exclusively for this work order. Time recorders see this as their budget for the task. If left at 0, no exclusive reservation is in place and the whole planning-line budget is available to draw from. Editable only on the Billing Work Order's lines (on a Sub-Work Order the cell is read-only, because reservation is held at the Billing Work Order level). See [Budget Reservation](/docs/pb/professional-services/work-order-business-rules.md#budget-reservation). * **Qty. Available to Reserve** — what is left of the planning-line budget after current reservations. Quantities under 8 hours are shown in hours; 8 hours or more are shown in days (1 day = 8 hours). Toolbar: * On a Billing Work Order: **⊕ Create Work Order Line** opens a dialog to pick a Project Task, Project Planning Line, and optional Activity, and adds a new line. * On a Sub-Work Order: **⊕ Get Work Order Line** opens a dialog showing the lines already defined on the parent Billing Work Order; the user picks one or more to bring onto the Sub-Work Order. * Lines can be deleted via the trash icon or the row context menu. #### Work Order Estimates * **Original Estimate:** The initially estimated effort; this value is displayed in the sidebar under "Time Recording" → "Estimated". * **Remaining Estimate:** Can be updated by the user to track the remaining effort. #### Time Recordings A list of all times recorded for this work order. Users with the *Planner* role can edit entries by double-clicking or using the context menu. New entries or deletions are not possible here. ### Planning Tab {#planning} This tab is for operational planning and resource assignment. * **Planning fields:** Here, the work order can be assigned to a primary resource, a resource group, and optionally a location, sprint, or area. * **Events:** Events are specific appointments or planned work blocks. The work on the work order can be planned in detail for one or more resources here, including specific start and end times. New events can be created via **⊕ NEW**. For more information, see the chapter [properties of a work order](/docs/pb/professional-services/work-order.md#properties). ### Details Tab {#details} This tab contains links, references, and historical data. * **External Link:** Specifies the origin of the work order and links it to the original element in an external system (e.g., a Jira issue or an Azure DevOps work item). * **Billing Work Order:** Used to map hierarchies. If this work order is a subordinate task, this section refers to the parent "Billing work order," on which all times are consolidated for billing. * **Link:** A direct, permanent link for quickly addressing this work order card. * **History (in the sidebar):** Shows when the work order was created and last modified. ### Sidebar The **sidebar** provides a quick overview of the work order's status: * **Planning:** * Scheduled: A status indicator (visualized by a green checkmark next to the resource) shows if the work order is scheduled. The checkmark appears as soon as at least one [Event](#planning) (planned work block) exists in the **Planning** tab, indicating that the work order has been scheduled. * Resource: Shows the primarily assigned resource. * **Time Recording:** * Estimated: The originally estimated effort in hours (this value comes from the **Original Estimate** field in the [Invoicing](#invoicing) tab). * Actual: The sum of all hours actually recorded for this work order, regardless of the recording resource. * **Budget:** * Budget Type: The budget type selected on the [Invoicing](#invoicing) tab. * Quantity: The budget set for the work order (e.g., in days), derived from the linked Project Planning Line (type *Budget*) (appears only if a Project Planning Line has been selected). * Actual: The portion of the budget already consumed (appears only if a Project Planning Line has been selected). ### Editing Permissions The editability of the fields is role-based: * ***Time Recorder* role:** Can edit descriptive and status-relevant fields like Title, Description, Internal Note, Solution, Type, Completed, Remaining Estimate, Area, Sprint. Cannot edit Customer, Project, Budget Type, or Work Order Lines (the project task, planning line, and activity now live on the line, not on the work order header). * ***Resource Planning* role:** Can edit all other structural and commercial fields, including Customer, Project, Budget Type, Original Estimate, and Planning Events. Can also create, get, edit (Activity, Reserved Qty.), and delete **Work Order Lines**. --- ## Setup(3) # Setup of DYCE Project & Resource Planning **DYCE Project & Resource Planning** is part of the parent [DYCE Connect Platform](/docs/web/introduction.md), which includes [Project and Resource Planning](/docs/web/prp/welcome.md) as well as [Time Tracking](/docs/web/tt/welcome.md). In addition to the [general settings](/docs/web/administration/setup-web.md) and the individual [user settings](/docs/web/administration/customization.md), specific planning parameters can be configured for each project. These are explained in detail in [project card](/docs/web/prp/planning/project-card.md) documentation. ## Display Options Most pages consist of a list and graphical elements. The display size of the elements can often be changed with the mouse. If the cursor is positioned between two elements, a movable border appears which can be moved. There are also two arrows which can be used to minimize, show and maximize an element. Fields can be added and removed in the lists. Right-click on the column header to display the list of all available fields. The desired fields can be selected from the list and the unwanted ones deselected. --- ## DYCE Connect # Welcome to DYCE Connect **DYCE Connect** is a platform that includes **[DYCE Time Tracking](/docs/web/tt/welcome.md)** and **[DYCE Project & Resource Planning](/docs/web/prp/welcome.md)**. Similar to Business Central, it is a web application that is hosted on Microsoft Azure. ## Home page Upon successful login, the home page is displayed first, showing the sections: * **Administration** (for setting up [Synchronization](/docs/web/administration/setup-sync.md) with Business Central and the [Setup](/docs/web/administration/setup-web.md) of **DYCE Connect**) * **[Time Tracking](/docs/web/tt/welcome.md)** * **[Planning](/docs/web/prp/welcome.md)** Which areas are visible depends, among others, on the role assigned to the logged-in user. Clicking on the respective buttons leads either to the general setup or to the start pages of the apps: the **[Dashboard](/docs/web/tt/time-tracking/dashboard.md)** of time tracking or the overview of **[Projects](/docs/web/prp/planning/projects.md)**. --- ## Automatic Activation # Automatic activation Instead of enabling Jira synchronization manually on every Customer or Contact, **Activation Rules** can automatically enable it based on configurable conditions. Open **Activation Rules** from a table mapping to configure rules for its source table. Each rule has: | Field | Meaning | |:--|:--| | Rule Type | The kind of condition to evaluate (see below) | | Description | Free-text description, pre-filled from the rule type when left empty | | Priority | Evaluation order; rules with a lower number are evaluated first | | Enabled | Whether the rule is applied | Rules are evaluated in priority order whenever a record is inserted or modified. As soon as one enabled rule matches, synchronization is activated for the record and no further rules are evaluated. ## Rule types * **All Records** Activates synchronization unconditionally for every record of the source table. Use this as a catch-all when all records should be synced. * **Create Customer From Contact** Activates synchronization for a Customer automatically created from a Contact through Business Central's *Create Customer from Template* process. Only rules that are enabled and match the current event are applied; a record that already has synchronization enabled is not affected by later rule evaluations. ## Combining with manual and mass activation Automatic activation rules complement, but do not replace, the other ways to enable synchronization described in [Table and field mapping](/docs/dcj/administration/mapping.md#mass-enabling-synchronization-for-existing-records): manually enabling **Enable Jira Sync** on a record, or mass-enabling it for a set of existing records with **Select Records to Sync**. All three ultimately set the same field and are subject to the same prerequisites (an enabled table mapping with a working OAuth2 connection and at least one enabled field mapping). --- ## Job Queue(Administration) Synchronization messages are processed in the background by a recurring **Job Queue Entry**, managed from the **Jira Setup** page. ## Setting up the job queue 1. Open **Jira Setup**. 2. Select **Initialize Job Queue** to create the job queue entry. It runs the message processing codeunit as a recurring job, scheduled every day of the week, starting immediately. 3. Select **Start Job Queue** to set it to *Ready* so it starts processing on its configured schedule. 4. Use **Open Job Queue Entry** to open the job queue entry card directly, for example to change its schedule using the standard Business Central job queue fields, or **Stop Job Queue** to put it *On Hold*. 5. Select **Refresh Status** to update the **Job Queue Status** and **Job Queue Last Run** fields shown on the setup page. :::tip The job queue entry uses the standard Business Central job queue, so it must run under a user with sufficient permissions, and the Business Central job queue itself must be active for the environment. ::: ## General settings The **General Settings** section on **Jira Setup** controls how messages are processed: | Field | Meaning | Default | |:--|:--|:--| | Refresh Threshold (Minutes) | How often the job queue entry runs | 10 | | Default Priority | Priority used for messages whose entity configuration does not specify one | 500 | | Max Retry Count | Maximum number of retry attempts for a failed message before it is marked **Failed** | 5 | | Retry Delay (Minutes) | Delay before a message scheduled for retry is attempted again | 5 | The same **Refresh Threshold** also determines how long an access token can remain unused before the job queue proactively refreshes it, so tokens stay valid between runs. ## What happens on each run Every run: 1. Refreshes the OAuth2 access token for every enabled OAuth2 setup that needs it. 2. Processes pending and due retry messages in ascending **Processing Priority** order (lower number first) - by default, Organizations are processed before Customers, and other entity types follow the *Default Priority*. 3. Commits progress every 50 processed messages, and stops after 1,000 messages so a single run cannot block the job queue for too long; remaining messages are picked up on the next run. A message that fails is either scheduled for **Retry** after the configured **Retry Delay**, or marked **Failed** once **Max Retry Count** is reached - see [Understanding messages](/docs/dcj/messages.md) for the full set of statuses and how to act on them. ## Message queue statistics **Jira Setup** also shows **Total Messages**, **Pending Messages** and **Failed Messages**, each linking to the corresponding filtered view of the [Jira Message Queue](/docs/dcj/messages.md). The **Navigate** action group provides quick access to the **Message Queue**, **OAuth2 Setup** and **Table Mappings** pages. --- ## Table and Field Mapping # Table and field mapping A **Jira Table Mapping** defines that a Business Central table is synchronized to a specific Jira entity type. ## Supported combinations {#supported-combinations} Currently supported combinations are: | BC Source Table | Jira Entity Type | Jira REST resource | |:--|:--|:--| | Customer | Organization | `/rest/servicedeskapi/organization` | | Contact (Person type only) | Customer | `/rest/servicedeskapi/customer` | Only one enabled table mapping is allowed per BC table and Jira entity type combination. ## Entity configuration The **Jira Entity Configurations** page defines, per Jira entity type, the REST endpoint and processing rules used by every table mapping for that entity: | Field | Meaning | |:--|:--| | Jira API Endpoint | Relative REST resource used to create or update the entity | | Jira API Endpoint (Delete) | Relative REST resource used to delete the entity; supports `{entityId}`/`{organizationId}` placeholders | | Default Processing Priority | Default priority used for messages of this entity type when the mapping does not override it (lower number = processed first) | | Prevent Delete | Blocks delete operations from being queued for this entity type | | Prevent Standard Field Change | Blocks changes to standard fields once the record has already been synced | | Create if Update Fails | Queues a new create message when an update fails because the target no longer exists in Jira | Default entity configurations for Organization and Customer are created automatically the first time the onboarding wizard or **Initialize Defaults** action runs. The **Test Configuration** action on the entity configuration card shows the resolved endpoint together with all enabled table mappings that use it. ## Table mapping On the **Jira Table Mapping** card, the **Business Central Source** and **Jira Target** sections define the BC table and Jira entity type, and can no longer be changed once the mapping is **Enabled**. The **Connection** section selects the **OAuth2 Setup Code** to use, with an optional **Base URL** override. The **Status** section shows the mapping **Description** and the number of **Active Fields**. Enabling a mapping is only possible when: * an OAuth2 setup is selected and has both a Client ID and client secret, * the OAuth2 setup has a **Cloud ID** (that is, it has completed authorization), and * a **Base URL** is available, either on the mapping or on the OAuth2 setup. Disabling a mapping is blocked while pending, processing or retry messages still exist for it. Actions available on the table mapping card: * **Create Default Mappings** - creates a recommended set of field mappings for the selected entity type (see [Field mapping](#field-mapping)). * **Select Records to Sync** - mass-enables synchronization for existing records (see [below](#mass-enabling-synchronization-for-existing-records)). * **Activation Rules** - configures automatic sync activation (see [Automatic activation](/docs/dcj/administration/auto-activation.md)). * **Open Entity Configuration** - opens the entity configuration card for the mapped entity type. * **Get Available Spaces** - loads Jira Service Management spaces for [space assignment](#assigning-records-to-jira-service-management-spaces). * **Test Mapping** - builds a sample payload from the first record of the source table, without sending it to Jira. * **Validate Against Jira** - checks that the custom fields used in the field mappings actually exist in Jira. ## Field mapping Field mappings, shown in the **Field Mappings** part of the table mapping card, define which Business Central field is sent to which Jira field: | Field | Meaning | |:--|:--| | Field Category | **Standard Field** (built-in Jira field, e.g. name) or **Custom Field** (organization-specific Jira field) | | BC Source Field | The Business Central field to synchronize | | Jira Field ID | The target field ID or name in Jira | | Jira Field Type | Text, Email, URL, Date, Number, Boolean, Phone, Select or Multi Select | | Default Value if BC Field Empty | Value sent to Jira when the BC field is empty | | Mapping Enabled | Whether the field mapping is active | | Field Purpose/Usage Description | Free-text note describing the field's purpose (hidden by default) | **Custom Field** mappings are sent to Jira through the organization/customer *detail fields* API rather than the standard create/update call, which requires additional OAuth2 scopes - see [Additional scopes - only applicable if using detail fields](/docs/dcj/administration/setup.md#detail-field-scopes). Only one field mapping is allowed per BC field within a table mapping. For custom fields, the Jira Field ID must be at least two characters, cannot contain `? : ; . = "`, and cannot be one of the reserved words *Name*, *Key*, *Created*, *Updated* or *Label*. The **Test Field Value** action shows the resolved value for the first record of the source table. Use **Create Default Mappings** on the table mapping card to populate a recommended set of field mappings for the chosen entity type; existing mappings are cleared after confirmation. ## Combined name Enabling **Enable Combined Name** on the table mapping lets Jira receive a name assembled from several Business Central fields, using a **Combined Name Template** with field names in curly braces, for example: ``` {No.} - {Name} ``` The resulting value is stored in the **Jira Combined Name** field on the Customer or Contact card. It is recalculated automatically whenever a template field changes on the record, and - when the combined name is enabled on the mapping for the first time - for every already sync-enabled record, tracked with a progress dialog. ## Mass-enabling synchronization for existing records Use **Select Records to Sync** on the table mapping to enable synchronization for many existing records at once instead of one by one: 1. Select **Select Records to Sync** on the table mapping card or list. 2. Use the standard filter dialog to narrow down the records to include. 3. Confirm the selection. All matching records that do not already have sync enabled are updated, and a confirmation message reports how many records were processed. Records are only queued if the table mapping and its field mappings are already fully configured, as described [above](#table-mapping). For Contacts, only records of type **Person** are considered, matching the [supported combinations](#supported-combinations). ## Assigning records to Jira Service Management spaces A **space** refers to a Jira Service Management service desk. Organizations and Customers can be linked automatically to one or more spaces when they are synced: 1. On the table mapping card, select **Get Available Spaces** to load spaces from Jira Service Management (requires an authorized OAuth2 setup). 2. Select the spaces to use and confirm; they are added to the **Assigned Spaces** part on the table mapping card. By default, every synced record is linked to all assigned spaces. To restrict a space to matching records only: 1. On the **Assigned Spaces** part, enable **Enable Filter** for the space. 2. Select **Edit Filter** to open the filter builder and define the criteria. 3. Use **View Matching Records** to check which records currently match, or **Clear Filter** to remove the restriction again (all records are then assigned). The filter builder is pre-populated with commonly used fields, though other fields of the source table can be added as well: | Source table | Pre-populated filter fields | |:--|:--| | Customer | No., Country/Region Code, Customer Posting Group, Customer Price Group | | Contact | No., Country/Region Code, Type, Company No. | When a Customer or Contact is synced and created in Jira, the connector automatically links the resulting Organization or Customer to every assigned space whose filter matches (or to all assigned spaces, if no filter is set for that space). --- ## Setup(Administration) **DYCE Connector for Jira Service Management** connects to Jira Service Management using an Atlassian OAuth 2.0 (3LO) app. Setup consists of registering that app in Atlassian, then running the **DYCE Connector for Jira Onboarding** wizard in Business Central, which creates the OAuth2 setup, table mapping and authorization in one guided flow. ## Prerequisites * A Jira Service Management site. * Rights to create an OAuth 2.0 app in the Atlassian Developer Console. ## Registering the OAuth 2.0 app in Atlassian 1. Open the Atlassian Developer Console and create a new **OAuth 2.0 integration**. 2. Under **Permissions**, add the Jira Service Management APIs the connector needs and grant the [required scopes](#required-scopes) listed below. 3. Under **Authorization**, set the **Callback URL** to: ``` https://app.dyce.cloud/jira/oauth/callback ``` Business Central cannot receive a browser redirect directly, so the callback is handled by a DYCE Connect page. That page displays the authorization code, which is copied back into Business Central to complete authentication. 4. Note the **Client ID** and generate a **Client secret**. The secret is only shown once by Atlassian, so store it safely until it is entered in Business Central. ## Required scopes Which scopes are required depends on whether only the standard organization and customer fields are synchronized, or whether [detail (custom) fields](/docs/dcj/administration/mapping.md#field-mapping) are also mapped. The onboarding wizard proposes a minimal starter set of scopes on its **Scopes and authorization** step (`manage:jira-organization`, `manage:jira-service-management-project`, `read:jira-user`, `read:servicedesk-request`, `write:jira-service-management-request`, `offline_access`); for a complete setup, use the scopes below instead. ### Scopes for organization and customer synchronization | Scope | Purpose | |:--|:--| | `offline_access` | Obtain a refresh token so access tokens can be renewed automatically | | `read:jira-user` | Read Jira user information (used to test the connection) | | `read:jira-work` | General read access to Jira | | `read:servicedesk-request` | Read service desk requests | | `write:servicedesk-request` | Create and update service desk requests | | `manage:servicedesk-customer` | Create and manage Jira Service Management customers (Contact → Customer synchronization) | | `read:servicedesk:jira-service-management` | Read service desks (spaces) | | `write:servicedesk:jira-service-management` | Manage service desks | | `read:servicedesk.organization:jira-service-management` | Read which organizations are linked to a service desk | | `write:servicedesk.organization:jira-service-management` | Link organizations to service desks ([space assignment](/docs/dcj/administration/mapping.md#assigning-records-to-jira-service-management-spaces)) | | `delete:servicedesk.organization:jira-service-management` | Unlink organizations from service desks | | `read:organization:jira-service-management` | Read organizations | | `write:organization:jira-service-management` | Create and update organizations (Customer → Organization synchronization) | | `delete:organization:jira-service-management` | Delete organizations | ### Additional scopes - only applicable if using detail fields {#detail-field-scopes} Field mappings with **Field Category** set to *Custom Field* are sent through Jira's organization/customer **detail fields** API instead of the standard create/update call, and therefore need these additional scopes. If no custom fields are mapped, they can be left out: | Scope | Purpose | |:--|:--| | `read:organization.detail:jira-service-management` | Read organization detail fields | | `write:organization.detail:jira-service-management` | Write organization detail fields | | `read:organization.detail-field:jira-service-management` | Read the organization detail field definitions | | `read:customer.detail:jira-service-management` | Read customer detail fields | | `write:customer.detail:jira-service-management` | Write customer detail fields | | `read:customer.detail-field:jira-service-management` | Read the customer detail field definitions | :::tip Create Service Management Setup The **Jira OAuth2 Setup List** page also offers a **Create Service Management Setup** action that creates a ready-to-use OAuth2 setup with all scopes above - including the detail field scopes - already applied. ::: ## Running the onboarding wizard Open **DYCE Connector for Jira Onboarding** from the Assisted Setup page, or search for it directly (*Alt+Q*). The wizard guides through four steps: 1. **OAuth setup** Reuse an existing, enabled OAuth2 setup, or create a new one by providing a **Setup code**, the **Client ID** from Atlassian, the **Base URL** (defaults to `https://api.atlassian.com`), the **Token endpoint URL** (defaults to `https://auth.atlassian.com/oauth/token`) and whether tokens should be refreshed automatically. Use **Open OAuth setups** to review or adjust the setup on the full list page. 2. **Table mapping** Reuse an existing table mapping, or create a new one by choosing the **BC Source Table**, the **Jira Entity Type**, a **Description**, and optionally enabling a [combined name](/docs/dcj/administration/mapping.md#combined-name). Field mappings for the new table mapping can be configured directly in this step. **Open entity configuration** shows the Jira REST endpoint used for the chosen entity type; see [Table and field mapping](/docs/dcj/administration/mapping.md) for details. 3. **Scopes and authorization** The wizard lists its starter set of [required scopes](#required-scopes) and, if **Apply required scopes automatically** stays enabled, writes them to the OAuth2 setup. Enter the **Client secret** and select **Start authorization** to begin the Atlassian consent flow described below. Review the [required scopes](#required-scopes) afterwards and extend the OAuth2 setup if detail (custom) fields will be mapped. 4. **Summary** Shows the OAuth2 setup and mapping status, the Cloud ID status, and the endpoint in use. From here, **Initialize job queue** and **Start job queue** set up background processing - see [Job Queue](/docs/dcj/administration/job-queue.md) for what this does. Select **Finish** to close the wizard. ## Authorizing with Atlassian Selecting **Start authorization** (or **Authenticate** on the **Jira OAuth2 Setup List**, described below) runs the following flow: 1. Business Central opens the default browser at the Atlassian authorization page. 2. Sign in with an Atlassian account that has access to the Jira Service Management site and approve the requested scopes. 3. Atlassian redirects to the DYCE Connect callback page, which displays an authorization code. 4. Back in Business Central, confirm that the code is visible, then paste it into the **Enter Authorization Code** dialog. 5. Business Central exchanges the code for an access and refresh token, stores them securely, and retrieves the **Cloud ID** and **Site URL** of the Jira site. Once authenticated, access tokens are refreshed automatically before they expire as long as **Auto Refresh Tokens** stays enabled; see [Job Queue](/docs/dcj/administration/job-queue.md) for how the refresh threshold is configured. ## Managing OAuth2 setups Multiple OAuth2 setups can be maintained on the **Jira OAuth2 Setup List** page, for example to connect to more than one Jira site. Each setup shows its **Base URL**, **Client ID**, **Auto Refresh Tokens** setting, current **OAuth Scopes**, and whether a client secret, access token or refresh token is stored, along with the **Last Token Refresh** and **Token Expires At** timestamps. Available actions: * **Create Service Management Setup** - creates a setup pre-filled with the complete Jira Service Management scope set (see [tip above](#required-scopes)), including the scopes only needed for detail fields. * **Authenticate** - runs the [authorization flow](#authorizing-with-atlassian) described above. * **Refresh Token** - manually refreshes the access token using the stored refresh token. * **Test Token** - calls the Jira API to confirm the stored token still works. * **Clear Tokens** - removes the stored access and refresh tokens, for example before re-authenticating with different scopes. :::note An OAuth2 setup cannot be deleted or renamed while it is referenced by a Jira table mapping. ::: ## Permissions Three permission sets are included with **DYCE Connector for Jira Service Management**. To review the permissions included in each one in detail, open the **Permission Sets** page (*Alt+Q*) and use the **Permissions** action. * **DYCEJiraRead (DYCE Connector for Jira Read)** Read-only access to all Jira Connector tables: OAuth2 setup, table and field mappings, entity configuration, activation rules, assigned spaces, and the message queue and its logs. Automatically included in the standard **D365 Basic - Read** permission set. * **DYCEJiraEdit (DYCE Connector for Jira Edit)** Adds insert, modify and delete rights for synchronization data: the message queue, message detail log, tracking requests and follow-up actions. This is the permission set needed to enable or disable sync and trigger a manual sync on a Customer or Contact, and to manage messages as described in [Understanding messages](/docs/dcj/messages.md). Includes **DYCE Connector for Jira Read** and is automatically included in the standard **D365 BASIC** permission set. * **DYCEJiraAdmin (DYCE Connector for Jira Admin)** Adds insert, modify and delete rights for configuration data: OAuth2 setup, table and field mappings, entity configuration, activation rule assignments and space assignments. Includes **DYCE Connector for Jira Edit** and is automatically included in the standard **D365 SETUP** permission set. The permission sets build on each other in this order: Read, Edit, Admin. Each is layered onto the corresponding standard Business Central permission set automatically, so most users do not need to be assigned a DYCE-specific permission set explicitly - only users without any of the standard D365 permission sets above do. For more information about permission sets, see this part of the Microsoft documentation. --- ## Creating Service Assets A **Service Asset** makes a Project Planning Line available in Jira as a Jira Assets object, so it can be attached to a Jira work item - for example as a custom field of that object type - and used there for automation or manual selection. A typical case is a recurring Subscription such as *Maintenance* or *Support* linked to a Project: creating a Project Planning Line for it with a Service Asset makes that planning line selectable on Jira work items. **DYCE Time Tracking** recognizes such a selection through the Service Asset's **Job Planning Line ID** attribute (the Business Central system ID of the underlying Project Planning Line) and, when present, presets a new time recording with the corresponding Project, Project Task and Project Planning Line. A Service Asset can be created automatically while creating a Project Planning Line, or manually afterwards; both ways create the same kind of record, synchronized to Jira the same way once [table and field mapping for assets](/docs/dcj/assets/mapping.md) is set up. ## Creating a Service Asset while creating a Project Planning Line In the **[Create Project Planning Line](/docs/pb/professional-services/project-planning-lines.md#create)** wizard, a **Service Asset** section offers a **Create Service Asset** toggle and a **Title** field, pre-filled from the planning line's description once a project and item are selected. Enabling the toggle and confirming the wizard with **OK** creates the Project Task, the Project Planning Line, and the Service Asset in one step. ## Creating a Service Asset manually Use **Create Service Asset** on a [Project Planning Line](/docs/dcj/assets/records.md#project-planning-lines) to open the **Create Service Asset** page: * A read-only section shows the Project Planning Line's context: Customer, Project No. and Description, Project Task No. and Description, Item No., Planning Line Description, and its source (see [Source granularity](#source-granularity) below). * If the planning line's source is a Contract or Subscription and no specific line has been chosen yet, a **Contract Line / Subscription Line** field allows picking one, filtered to lines that don't already have their own Service Asset - it is left blank to create the Service Asset at the Contract/Subscription header level instead. A header-level Service Asset can coexist with a line-level one for the same Project Planning Line. * In the **Service Asset** section, a **Title** (required, pre-filled from the planning line or the chosen contract/subscription line) and an optional **Long Description** are entered. Confirming with **OK** creates or updates the Service Asset. **Create Service Asset** stays available on the Project Planning Line as long as a Service Asset can still be created at a deeper granularity than what already exists for that line; once every available level already has a Service Asset, the action is no longer shown, and the existing Service Asset is opened and updated through the same page instead. ## Source granularity A Service Asset always records where it comes from, as one of: * **Project Planning Line** - the default, used when the line is not linked to a contract or subscription. * **Contract**, **Subscription** or **Subscription Line** - used when the Project Planning Line was [created from a Customer Subscription Contract or a Subscription](/docs/pb/professional-services/project-planning-lines.md), at the deepest level available: the specific line, if one was chosen, otherwise the contract or subscription header. The context copied onto the Service Asset - Customer, Project, description, quantity and so on - is kept up to date automatically as the underlying Project Planning Line, Project Task or Project changes. --- ## Table and Field Mapping for Assets # Table and field mapping for assets Asset mappings are a **Jira Table Mapping** with **Jira Entity Type** set to **Asset**, so the general concepts in [Table and field mapping](/docs/dcj/administration/mapping.md) apply here as well. This page covers what is specific to synchronizing assets. ## Supported source tables | BC Source Table | Asset Object Type | |:--|:--| | Customer | Customer | | Contact (Person type only) | Customer Employee | | Project | Project | | Service Asset | Service Asset | These are the object types created by the [default schema](/docs/dcj/assets/schema.md#default-schema); a mapping can also target a custom object type modeled as described in [Asset schema](/docs/dcj/assets/schema.md). Unlike Organization and Customer mappings, more than one enabled asset mapping is allowed for the same source table, as long as each targets a different asset object type - the [table filter](#table-filter) below decides which records go to which mapping. ## Creating an asset table mapping On a new **Jira Table Mapping**, set **Jira Entity Type** to **Asset**. The **Asset Configuration** section that appears is used to choose the **Asset Schema Code** and **Asset Object Type Code** to synchronize to - both must already be [Synced](/docs/dcj/assets/schema.md#sync-status-and-pushing-to-jira). Select the assets **OAuth2 Setup Code** ([setup](/docs/dcj/assets/setup.md)) as the connection, the same as for any other mapping. ## Field mapping For the Asset entity type, the **Field Mappings** part targets a schema **attribute** instead of a free-form Jira field ID: | Field | Meaning | |:--|:--| | Target Attribute | The Synced attribute of the mapping's object type to write to | | Source Type | **Field** (the value comes from a Business Central field) or **Constant** (a fixed value) | | Source Field No. | The Business Central field to synchronize, when Source Type is Field | | Constant Value | The fixed value to synchronize, when Source Type is Constant | | Transformation Rule | An optional transformation rule applied to the source value | An **Object Reference** attribute can only be targeted with Source Type Field, using a source field that has a table relation. ## Table filter Each asset mapping can be restricted to a subset of records with a table filter: 1. On the table mapping card, in the **Asset Configuration** section, select the **Table Filter** field. 2. Use the standard filter dialog to define which records the mapping applies to. 3. Confirm the filter. A record is only synchronized as an asset if it matches the table filter of at least one enabled asset mapping for its source table. An empty filter matches every record. ## Enabling synchronization * For **Customer** and **Contact**, asset synchronization is enabled the same way as Organization and Customer synchronization - see [Enabling and disabling synchronization](/docs/dcj/customer-contact.md#enabling-and-disabling-synchronization) and [Mass-enabling synchronization for existing records](/docs/dcj/administration/mapping.md#mass-enabling-synchronization-for-existing-records) in Table and field mapping. The same **Enable Jira Sync** field drives both the Organization/Customer synchronization and the asset synchronization for the same record. * For **Project**, turning on **Enable Jira Sync** on the [Project card](/docs/dcj/assets/records.md#project-card) starts synchronization for that project. * For **Service Asset**, there is no separate enable step - every Service Asset that matches an enabled mapping's table filter is synchronized automatically as soon as it is [created](/docs/dcj/assets/creating-service-assets.md). ## Automatic activation [Activation Rules](/docs/dcj/administration/auto-activation.md) can also be used on Customer and Contact mappings targeting the Asset entity type, using the same rule types described there. For Project and Service Asset mappings, the [table filter](#table-filter) above already determines which records are synchronized, so activation rules are not used. --- ## Customer, Contact, Project and Service Asset # What to see and do for asset synchronization Once [asset table and field mapping](/docs/dcj/assets/mapping.md) is configured, the Customer and Contact card each gain an additional field, the Project card gains a full Jira Integration section, and Project Planning Lines and the Service Asset list provide access to Service Assets. ## Customer card Adds to the existing Jira Integration section (see [Customer card](/docs/dcj/customer-contact.md#customer-card)): | Field | Meaning | |:--|:--| | Jira Asset ID | ID of the corresponding asset in Jira, once synced | **Enable Jira Sync**, **Manual Sync** and the other existing fields and actions cover both the Organization and the asset synchronization for the same customer. ## Contact card Adds to the existing Jira Integration section (see [Contact card](/docs/dcj/customer-contact.md#contact-card)): | Field | Meaning | |:--|:--| | Jira Asset ID | ID of the corresponding asset (Customer Employee) in Jira, once synced | Since a contact's Jira customer and its Jira asset (Customer Employee) are synchronized independently, an additional **Manual Synchronization (Asset)** action queues an immediate asset synchronization message, alongside the existing **Manual Synchronization** action for the Jira customer. ## Project card The Project card gets a new **Jira Integration** section: | Field | Meaning | |:--|:--| | Enable Jira Sync | Enables synchronization of this project as a Jira asset | | Jira Sync Status | Status of the latest synchronization message; select it to open that message | | Last Jira Sync | Date and time of the last synchronization attempt | | Jira Asset ID | ID of the corresponding asset in Jira, once synced | Actions, under the **Jira** action group: **Manual Synchronization** queues an immediate synchronization message; **View Message Queue** opens the [message queue](/docs/dcj/messages.md) filtered to this project. ## Project Planning Lines Each Project Planning Line shows whether it already has a linked Service Asset in the **Service Asset Created** field; selecting it opens a read-only view of the linked Service Asset(s) - a line sourced from a Contract or Subscription can have both a header-level and a line-level Service Asset at the same time, and both are shown. A **Jira Integration** action group adds: * **Create Service Asset** - opens the [Create Service Asset](/docs/dcj/assets/creating-service-assets.md) page for this line. Only shown while a Service Asset can still be created for the line, at a granularity not already used. * **View Service Assets** - opens a read-only view of the Service Asset(s) linked to the line. On the [Project Planning Lines page opened from a Contract or Subscription](/docs/pb/professional-services/project-planning-lines.md), a **Service Assets** action additionally opens a read-only, task-level view of every Service Asset linked to planning lines under the selected Project Task. ## Service Asset list The **Service Assets** page lists every Service Asset, together with its source context (Project, Project Task, Customer, planning date, quantity, description, and - where applicable - the linked Contract or Subscription) and its Jira synchronization status, last sync time and Jira Asset ID. :::note Service Assets cannot be created, changed structurally or deleted from this list - they are managed through [Creating Service Assets](/docs/dcj/assets/creating-service-assets.md) and kept up to date automatically from their source. There is no per-record synchronization toggle: a Service Asset is synchronized automatically as soon as an enabled mapping's [table filter](/docs/dcj/assets/mapping.md#table-filter) matches it. ::: Actions: **Manual Sync** queues an immediate synchronization message; **View Messages** opens the [message queue](/docs/dcj/messages.md) filtered to this Service Asset. --- ## Asset Schema # Asset schema Jira Assets (Insight) organizes data in a **schema**, made up of **object types** (for example Customer or Project), each with its own **attributes** (for example Name or Country). Before Business Central records can be synchronized as assets, this structure needs to exist in Business Central - either created automatically as a recommended default, or modeled manually to match an existing Jira Assets schema. ## Default schema On the **Jira Asset Schemas** page, select **Create Default DYCE Schema** to create the recommended starting point in one step: a schema named **DYCE Business Central** (code `DYCE_CORE`, schema key `DYCEBC`) with four object types - **Customer**, **Customer Employee**, **Project** and **Service Asset** - together with their attributes and the matching [table and field mappings](/docs/dcj/assets/mapping.md). This can be run repeatedly; configuration that already matches is reused rather than duplicated. The **Service Asset** object type's **Job Planning Line ID** attribute carries the Business Central system ID of the underlying Project Planning Line; **DYCE Time Tracking** uses it to preset time recordings - see [Creating Service Assets](/docs/dcj/assets/creating-service-assets.md). ## Schema, object type and attribute | Page | Shows | |:--|:--| | Jira Asset Schemas | All schemas, with Code, Name, Schema Key, Sync Status and Jira ID | | Jira Asset Schema Card | Code, Name, Schema Key (2-10 uppercase letters or digits), Description, OAuth Setup Code, Sync Status, Jira ID, and the object types belonging to the schema | | Jira Asset Object Type Card | Schema Code, Code, Name, Icon ID, Sync Status, Jira ID, and the attributes belonging to the object type | | Jira Asset Attributes (part on the object type card) | Code, Name, Data Type, Options (Select data type only), Is Mandatory, Is Unique, Reference Object Type (Object Reference data type only), Sync Status | Every new object type automatically receives a mandatory, non-deletable system attribute named **Name**. ## Attribute data types Each attribute has one of the following data types: **Text**, **Integer**, **Boolean**, **Date**, **Date Time**, **URL**, **Email**, **Select**, or **Object Reference**. An Object Reference attribute points to another object type within the same schema (its **Reference Object Type**), and can only be targeted by a field mapping whose Business Central source field has a table relation - see [Field mapping](/docs/dcj/assets/mapping.md#field-mapping). ## Sync status and pushing to Jira Schemas, object types and attributes each carry a **Sync Status**: **Draft** while only defined in Business Central, and **Synced** once pushed to Jira. A Synced record can no longer be edited directly in Business Central; to change it, adjust the corresponding record in Jira, or add a new Draft attribute and push it separately. Actions: * **Push to Jira** - available while the schema is Draft; creates the schema, its object types and their attributes in Jira Assets, and marks them Synced. * **Push New Attributes** (Jira Asset Schemas list) / **Push Additions** (Jira Asset Schema card) - available once the schema is Synced; pushes only attributes added since, without affecting what already exists in Jira. Deleting a schema, object type or attribute that is already Synced asks for confirmation, since it is not removed from Jira by doing so. Deleting one still used by a table mapping, a field mapping, or as the target of an Object Reference attribute is not possible. --- ## Asset Synchronization Setup # Asset synchronization setup In addition to synchronizing Customers and Contacts to Jira organizations and customers, **DYCE Connector for Jira Service Management** can synchronize Customers, Contacts, Projects and Service Assets to Jira as **Jira Assets** (Insight) objects. Asset synchronization builds on the same OAuth2 mechanism described in [Setup](/docs/dcj/administration/setup.md), but needs its own scopes and one additional piece of configuration. ## Prerequisites * Jira Assets (Insight) enabled on the Jira Service Management site. * The general **DYCE Connector for Jira Service Management** [setup](/docs/dcj/administration/setup.md) already completed, or being set up alongside asset synchronization. * Rights to edit the OAuth 2.0 app used, in the Atlassian Developer Console. ## OAuth2 setup for assets Asset synchronization uses the same **Jira OAuth2 Setup** table as Organization and Customer synchronization, typically as its own setup record because it needs a different set of scopes. On the **Jira OAuth2 Setup List**, select **Create Assets Setup** to create a ready-to-use setup with setup code **ASSETS-OAUTH**, the default **Base URL** (`https://api.atlassian.com`), and all [required scopes](#required-scopes) already applied. If a setup with this code already exists, confirm to overwrite it. Add the same scopes to the OAuth 2.0 app in the Atlassian Developer Console - see [Registering the OAuth 2.0 app in Atlassian](/docs/dcj/administration/setup.md#registering-the-oauth-20-app-in-atlassian) for the general steps. A separate app can be registered for assets, or the existing one extended with the additional scopes below. ## Required scopes | Scope | Purpose | |:--|:--| | `offline_access` | Obtain a refresh token so access tokens can be renewed automatically | | `read:jira-user` | Read Jira user information (used to test the connection) | | `read:jira-work` | General read access to Jira | | `read:servicedesk-request` | Read service desk requests | | `read:cmdb-object:jira` | Read Jira Assets objects | | `write:cmdb-object:jira` | Create and update Jira Assets objects (Customer, Customer Employee, Project and Service Asset synchronization) | | `read:cmdb-schema:jira` | Read Jira Assets schemas | | `write:cmdb-schema:jira` | Create and update Jira Assets schemas | | `read:cmdb-type:jira` | Read Jira Assets object types | | `write:cmdb-type:jira` | Create and update Jira Assets object types | | `read:cmdb-attribute:jira` | Read Jira Assets attribute definitions | | `write:cmdb-attribute:jira` | Create and update Jira Assets attribute definitions | | `read:cmdb-config:jira` | Read Jira Assets workspace configuration (used to look up the Workspace ID) | :::tip Create Assets Setup **Create Assets Setup** on the **Jira OAuth2 Setup List** already applies all of the scopes above - add them manually only if the setup is created a different way. ::: ## Authorizing and finding the Workspace ID Authorization works the same way as for any other OAuth2 setup - see [Authorizing with Atlassian](/docs/dcj/administration/setup.md#authorizing-with-atlassian). Jira Assets additionally identifies the target workspace by a **Workspace ID**, shown on the OAuth2 setup card. Once authorized, select **Lookup Workspace ID** to discover and fill it in automatically. Asset synchronization fails with a missing workspace error until this field is populated. ## Permissions Asset synchronization uses the same [permission sets](/docs/dcj/administration/setup.md#permissions) as the rest of the connector - Read, Edit and Admin - extended to also cover the asset schema, object type, attribute and field mapping tables, and the Service Asset table. No separate permission set is needed. --- ## Customers and Contacts # What to see and do on Customer and Contact Once [table and field mapping](/docs/dcj/administration/mapping.md) is configured, both the **Customer Card** and **Contact Card** get a **Jira Integration** section. :::note Enabling synchronization requires **DYCE Connector for Jira Service Management** to be activated. See the DYCE Activation Status page if synchronization cannot be enabled for this reason. ::: ## Customer card | Field | Meaning | |:--|:--| | Enable Jira Sync | Enables synchronization of this customer as a Jira Organization | | Jira Sync Status | Status of the latest synchronization message; select it to open that message | | Last Jira Sync | Date and time of the last synchronization attempt | | Jira Organization ID | ID of the corresponding organization in Jira, once synced | | Jira Combined Name | The [combined name](/docs/dcj/administration/mapping.md#combined-name) sent to Jira, if enabled on the table mapping | Actions: **Manual Sync** queues an immediate synchronization message for this customer; **View Messages** opens the [message queue](/docs/dcj/messages.md) filtered to this customer. ## Contact card | Field | Meaning | |:--|:--| | Enable Jira Sync | Enables synchronization of this contact as a Jira Customer (Person type contacts only) | | Jira Customer ID | ID of the corresponding customer in Jira, once synced | | Jira Sync Status | Status of the latest synchronization message; select it to open that message | | Last Jira Sync | Date and time of the last synchronization attempt | | Jira Combined Name | The [combined name](/docs/dcj/administration/mapping.md#combined-name) sent to Jira, if enabled on the table mapping | Actions: **Sync to Jira** queues an immediate synchronization message for this contact; **View Message Queue** opens the [message queue](/docs/dcj/messages.md) filtered to this contact. ## Enabling and disabling synchronization Turning on **Enable Jira Sync** validates that the record can actually be synced and reports a clear error otherwise, for example a missing enabled table mapping, an unauthorized OAuth2 setup, or no enabled field mappings. Once enabled, the record status changes to **Pending** and the first synchronization message is queued. Turning **Enable Jira Sync** back off does not delete the record in Jira. If unprocessed messages still exist for the record, disabling asks for confirmation and cancels those pending messages. --- ## Understanding Messages # Understanding messages Every change that needs to be synchronized to Jira is recorded as a message in the **Jira Message Queue**, together with the resulting JSON payload, its processing status, and a detailed log. The queue can be opened directly, from **Jira Setup**, or from a Customer, Contact, Project or Service Asset's **View Messages** (or **View Message Queue**) action. ## Message status | Status | Meaning | |:--|:--| | Pending | Waiting to be processed | | Processing | Currently being sent to Jira | | Completed | Synchronized successfully | | Completed with Warnings | Synchronized, but with a warning worth reviewing (shown in **Status Details**) | | Failed | Synchronization failed after all retry attempts were used | | Retry | Failed, but will be attempted again at the **Next Retry Time** | | Cancelled | Removed from processing, for example after synchronization was disabled while messages were still pending | **Status Details** holds the error message for a failed or warned attempt. Select **View Detail Logs** - or check the **Message Log Details** FactBox - for the full chronological log of a message, including status changes and processing notes. ## Operation type | Operation | Meaning | |:--|:--| | Create | Creates a new entity in Jira | | Update | Updates an existing entity in Jira | | Delete | Removes the entity from Jira | | Manual Sync | Triggered by the **Manual Sync** action on a Customer or Contact | | Follow-Up Action | A dependent action queued after another message completed, for example [assigning a newly created organization to a space](/docs/dcj/administration/mapping.md#assigning-records-to-jira-service-management-spaces) | A follow-up message only becomes eligible for processing once its parent message has reached **Completed** or **Completed with Warnings**. ## Manual processing actions The **Manual Processing** action group on the message queue supports handling messages without waiting for the job queue: * **Send Selected Message** - sends the selected message immediately; only available for messages in **Pending**, **Retry** or **Failed** status. * **Delete Selected Message** - removes the message from the queue; if the message has related follow-up messages, they are deleted together with it after confirmation. * **Reset Stuck Messages** - resets messages that have been stuck in **Processing** for more than 5 minutes back to **Pending**, for example after an unexpected interruption. * **Reset Failed/Cancelled Message** - resets a **Failed**, **Retry** or **Cancelled** message back to **Pending** so it is picked up again; not available for **Completed** messages. * **Show JSON Payload** - displays the exact payload that was, or will be, sent to Jira for the selected message. ## Message status on Customer and Contact The **Jira Sync Status** field on the Customer and Contact card mirrors the status of the latest message for that record and can be selected to jump directly to it - see [What to see and do on Customer and Contact](/docs/dcj/customer-contact.md). The same applies to the Project card and the Service Asset list - see [Customer, Contact, Project and Service Asset](/docs/dcj/assets/records.md). --- ## Powered by MDX You can write JSX and use React components within your Markdown thanks to [MDX](https://mdxjs.com/). The `.mdx` extension is not required, but will enable better support from tooling (IDE, Prettier...). export const Highlight = ({children, color}) => ( alert('Highlight pressed!')}> {children} ); Docusaurus green and Facebook blue are my favorite colors. I can write **Markdown** alongside my _JSX_!