-
Provide possibility to limit number of available enum values
We are looking for a possibility to limit the number of available enum values shown to the customer. For example, in certain dropdown lists we want to limit the number of available options available to the customer. An example is the Journal type under which we can specify on the Journal Names (General ledger > Journal setup > Journal names). There are a lot of elements (available in base enum LedgerJournalType). We would like functionality to limit the number of elements available for selection. In previous versions of Dynamics AX, this could be done by changing the Configuration Key on a base enum element. In an extension, it is no longer possible to change the Configuration Key property on the element.
-
General improvements on batch transfer for subledger journals
When using the "batch transfer for subledger journals" functionality, a batch job is created. But for the actual execution of the batch transfer, it creates a new batch job for the actual subledger transfer. This is not good design, since we don’t have the actual execution times in the original batch jobs then. Also, these “new” batch jobs are removed, so that no detail remains available. Also, we can enter filters when creating the batch, but it is not good design that these filters are not available when looking up the batch job filters afterwards. Also if the job does not recurrent we want to keep this parameters for review afterwards. We found out that we were able to execute the batch transfer filtered by period by entering both fiscal year and period name. Only entering fiscal year will cause the batch transfer being executed for ALL periods. This is not clear and should not happen! Either the month should be required when entering a fiscal year or the filter should work when only a fiscal year. The status once the process has started is not clear. The records are removed from the “Subledger journal entries not yet transferred” listpage almost immediately, while in reality they are still in process. -
Split up payment file generation and post processing actions like setting payment status
Right now, when a payment journal is created, you can click functions > generate payments in order to generate the payment file. Next to generating the payment file, post actions are done like updating the Payment status to "Sent". Since this is done in the same process, it can happen that the payment status is not updated while the file was actually generated due to a transient error (memory issue, database connection loss). We suggest to resolve this by creating a batch job that will create 2 runtime tasks: * 1 for actually creating the xml file and storing it * 1 for doing post processing (like updating payment status and direct debit mandates)
You’re offline. This is a read only version of the page.
