Public Profile
  • Change project contract

    A recent update based on KB3178570 made it impossible to change the project contract after project transactions were made. This was done to prevent a problem in a specific scenario. However, this also caused a regression in functionality.

    All information from the project contract is stored in the project transactions, including the funding source. To that end changing the project contract on a running project should be possible. This allows users to change the customer (and other commercial details) of a running project for all new transactions. In the meanwhile the existing transactions can be invoiced based on the old project contract.

    This functionality is even more needed since a funding source cannot be change while project transactions exist (which is good) and working with multiple funding sources is not allowed when working with item requirement and/or project salesorders.

  • Allow multiple funding sources in conjunction with item requirements

    Working with item requirements is not allowed if multiple funding sources are setup in the project contract that is attached to the project.

    It would be very helpfull if a design change was made which allowed working with item requirements and/or project sales orders in conjunction with a project contract with multiple funding sources.

  • Adjust team member security roles for full read and workflow approval

    Based on licence documentation a user which has only roles for team members, in other words a team member user has the following rights:

    • Full read access across the entire application
    • Work with work items in workflow processes like purchase invoice approval

    With the current roles both options won't work. Only very limited read access is granted and no work items can be created for users which only have team member roles.

    This was replicated and acknowledged in two earlier service request, the last one having the number REG:117103116584637.

  • Retrieve the "finished items in process" report as known from earlier AX versions

    The report "Finished items in process" was part of AX 2012 alongside with it's companions "Materials in process", "Work in process" and "Indirect costs in process". The latest three mentioned are still present in Dynamics 365, but the "Finished items in process" report is gone. It would be very nice if this report could be re-introduced to Dynamics 365. Also a report that breaks down the WIP accounts in GL into production orders with the labor, materials, indirect costs and reported as finished would be very welcome. In AX 2012 we had to combine the 4 above mentioned reports, even this is no longer possible.

  • Sales tax registration numbers in multiple European countries in one legal entity

    Companies in Europe can have warehouses in multiple countries. Examples are consignment stock at a customer, toll manufacturers in another country or just having a warehouse close to the customers to have the shortest possible delivery times. These customers typically do not have a business / legal entity in those countries. Since there is free movement of goods in the European Union, this occurs more and more. Also with the product growing rapidly towards the enterprise market we see more and more customers with warehouses in different member states of the European Union. In most cases within the European Union, you must register for sales tax in that specific country if you ship goods to and sell from a foreign warehouse. An example. A Dutch company has a manufacturing plant in the Netherlands, but they also have a warehouse in Southern Germany to be able to deliver to every destination in Europe within a day's truck drive. In this case the company is legally located in the Netherlands, but they hold sales tax registration numbers in both the Netherlands and Germany. This leads to the following scenario's. If they replenish the German warehouse using a transfer order this has to be declared for both Intrastat and Sales tax. Intrastat functionality supports the transfer order. However the transfer order is no input for sales tax declaration nor EU sales list. The goods are moved from their Dutch Sales tax registration number to their German Sales tax registration number. If they continue to sell to a German company from the German warehouse this has to be calculated as domestic German sales tax and they have to register and declare this on their German Sales tax number. Current functionality is not able to determine the correct Sales tax group based on the customer master data. This customer has been setup to be serviced from the Dutch warehouse, so the setup on the customer master will trigger a sales tax calculation as if the goods were shipped from the Netherlands to Germany. The sales tax group has to be changed manually which comes with a big risk on picking the wrong value or just forgetting to think about changing the value. It would be ideal if the sales tax group would also be determined by the location of the warehouse where the goods are shipped from. If they sell to an Austrian company from the German warehouse, this has to be calculated as a German EU trade transaction, to be declared on the German Sales Tax number and the German EU sales list at the German tax authority. However, by default this customer has been setup for shipment from the Dutch warehouse. Despite the fact that we are able to setup multiple tax authorities in the system, this doesn't tick all the requirement boxes. A lot of sales tax settings are on the legal entity level and not on the sales tax authority level. An example is conditional sales tax, this means sales tax has to be declared when the invoices are paid. This applies for France and can only be set on a legal entity level. Another example is the EU sales list. This is based on the list of countries as specified in the foreign trade parameters. However, if a country is domestic, "other EU member state" or "rest of the world" can only be set up from the point of view of the legal entity address whereas the legal entity is located in multiple countries for the sales tax. Sales tax and intrastat functionality is supported by localizations that are enabled on the legal entity level. This mean that a Dutch company can only use the Dutch localization features for sales tax and intrastat functionality and declarations. This means that they lack the functionality to electronically declare sales tax, EU sales list and Intrastat in all other countries apart from the Netherlands. Finally, scenario's in which the goods are shipped from another country then the country in which the legal entity has it's primary address are not supported well. Sales tax is dependent on the country which the goods are shipped from, the country where the goods are shipped to and the delivery term. The functionality is highly needed on sales and purchase orders. Projects would also be nice, but this is a less common scenario. A basic overview of the requested functionality would be - Be able to setup multiple Sales tax registration numbers so the correct number can be mentioned on the sales orders, most likely on the sales tax settlement period or the tax authority - Correct determination of the sales tax group on purchase and sales order lines based on the country where the goods are shipped from, country which the goods are shipped to and the delivery term. Also the list code should be determined based on these parameters to ensure a correct EU sales list - Adjust the summary update parameters to prevent sending out an invoice with sales tax calculated for multiple sales tax registration numbers - Move some of the sales tax settings and localization features from the legal entity level to the tax authority level. An example is conditional sales tax on the sales tax tab of general ledger parameters. - Move almost all settings from the foreign trade parameters in the tax module to a lowel level to be able to support multiple EU sales lists and intrastat declarations from one legal entity I am more than happy to discuss further details and to participate in the next steps. Kinds regards, Jasper Schram