Public Profile
  • Ledger settlement - add 'last settlement date' column

    Ledger settlements enable user to create an overview of due amount on ledger accounts. This functionality is mainly used by accountants to prepare balance sheet specifications. However when accountants are trying to prepair annual reports, they can't request this information historically. AX will only provide an overview of which amount aren't settled. By adding the 'last settlement date' column, accountants are able to account for the balance position at eg. 31-12-2016. 

    The 'settlement date' value should be populated with the highest transdate value of the ledger transactions selected in the ledger settlement (last date of the ledger transactions with the same settlementId).

    This column can be added to the LedgerTrans table and or LedgerTransSettlement table. I guess this depends on the way this functionality gets embedded elsewhere. Visualizing this column might be useful as, one or more older transactions slip in the ledger settlement. It makes it easier to spot errors and also clarifies the progression of the account. 

    It's a minor adjustment but provides great insight.

  • Prepopulate project dimension on the project table

    If the project dimension is enabled the project dimension should equal the project id upon creation of a new project. Perhaps this can be a new parameters setting.

    This is modification is always requested when the project module is used. 

    The same principle can be applied for other financial dimensions such as fixed assets, vendors, customers, released products, etc.

  • Financial dimension attributes

    A lot of customer require to ability to report on financial dimension in hierarchies. To support this requirement users can build dimension hierarchies, use number sequence logic in the dimension code or use dimension totals. These options don't allow for easy reporting using PowerBI. The financial dimension value attributes (just like product attributes), would fit better with the PowerBI reporting strategy.

  • New participants for Organisation hierarchy (new "start from" participants)

    Organisation hierarchy has one big flaw: the "start from" function. There are generally only two options: 1) the workflow originator 2) or the workflow owner This has a few limitations. As people can submit AP documents centrally, the prime example being AP invoices. Organisations want to use the DImension participants in conjunction with the Organisation hierarchy to benefit from spending and approval limits. This functionality isn't currently available when only relying on workflow participants.
  • New participants for Organisation hierarchy (new "start from" participants)

    Organisation hierarchy has one flaw: the "start from" function. There are generally only two options: 1) the workflow originator 2) or the workflow owner This has a few limitations. Businesses can decide to submit AP documents centrally, the prime example being AP invoices. When AP invoices are submitted centrally and AP invoices have to be approved decentralised, users are unable to utilize the Organisation hierarchy functionality. Organisations want to use the Dimension participants in conjunction with the Organisation hierarchy to benefit from spending and approval limits. This functionality isn't currently available when only relying on workflow participants.
  • Add conditions to project timesheet approval workflow

    The project timesheet approval workflow has a very limited amount of workflow conditions. The following scenarios cannot be configured due to its restrictions: - different approver based on the project group or other project related field - different approver based on the resource or associate role Adding the project table, project resource and other related table to the workflow conditions would provide the flexibility that companies need.
  • Project timesheet policy types

    Like the vendor invoice policies, the project timesheet policy should have the option to apply different policies to different scenario’s. For example, if a project resource is associated to a default calendar of 20-hour, this resource doesn’t have to comply with the company project timesheet policy which is 40-hours but rather has to comply with the 20-hour project timesheet policy. The policy can then ensure that every resource can only submit the timesheet if their timesheet includes the number of hours prescribed by their calendar.

  • Report on late project timesheet submission and approval

    Lots of companies report on late project timesheet submissions and approvals. This functionality would be very useful and is requested by a lot of clients.

  • Include Location in WBS tasks

    When users are scheduling activities using the project WBS it would be very useful to be able to include the location, or place where the tasks needs to be executed. A prime example would be, where the WBS tasks is a discovery workshop which must be completed whilst on site.

  • Improve link between WBS tasks and Activities

    To improve the link between WBS tasks and Activities I suggest the following improvements: Currently, WBS tasks create an Activity appointment when the WBS is linked to a project quote but when linked to a project, the WBS tasks will create an Activity of type task. It would be great if users have the flexibility to choose what type of Activity the WBS task will create. When users are scheduling activities using the project WBS it would be very useful to be able to include the location, or place where the tasks need to be executed. A prime example would be, where the activity is a discovery workshop which must be completed whilst on site. A synchronisation between WBS task and Activity for values such as Start date, Responsible (task assignment), Location and Activity type. A synchronisation between the Activity completion and WBS tasks completion would be very useful so, users can complete tasks via outlook.