Mark Schurmann Automobile Protection Corp.

When an item is submitted to workflow, it should be automatically validated.  If the validation fails, the submittal should be terminated.  If the validation generates a warning, the user should be prompted whether to continue with the submittal.

We've had several instances where an unbalanced or flawed journal has been submitted and approved only to fail when it is posted.  There is also a know bug that will double book a journal.  We've had this happen twice and it seems to be related to workflow items.  Validation prior to submittal would potential reduce this risk.

There are many data entities related to workflow but there does not seem to be any that show the workflow history.  There needs to be data entities that show the approvals of a work item and the business entity (GJ, AP Invoice, PO, etc.) to which the work item is associated.

This information is extremely useful for audit reporting.  Where available the following fields should be included on all data entities:

CREATEDDATETIME

CREATEDBY

MODIFIEDDATETIME
MODIFIEDBY

There does not appear to be a way to filter a column on blank fields.  In addition, if you attempt to back into row with blank values by using "not equal" or "not contains", the rows with blank values are excluded because they have null values.  

Please provide additional filter options "is blank" and "is not blank".

If a collection letter is created but then cancelled before printing or posting, it does not have much use. It does not seem to impact the creation of the next collection letter. Perhaps there is a reason to maintain the cancelled letters, but to me they are needless clutter. Please provide the ability to delete these from the system after cancellation.

The collection letters show only the open amount on the invoice. This is fine, but would be more useful to inform the customer about the status of the invoice. It would be good to note the original amount of the invoice and the sales tax on the invoice. We have a lot of problems with customers shorting the payment by the sales tax amount. Generally, this is just an oversight. If the sales tax were displayed on the collection letter it would be a clue to the customer way the invoice is still open.

There is often a need to have multiple development instances. Rather than require users to request a new instance and then have to deploy packages and refresh the AxDb database to provision another development environment, provide an option to simply clone an existing instance.

With the coming "hardening" of the test environment, it will be more difficult to access the AxDb using Sql. Perhaps with this hardening, Microsoft will also provide an easier way to refresh a development instance, but I think the best solution to this is to allow the Build environment to be a target when making a refresh from production request. This would also make the build environment more useful for smoke testing and troubleshooting.

We are in the process of upgrading our production environment to 8.0. It has not gone well. All SSRS reports are broken. I've updated the status of the service request to "Validation Failed" with comments. I've also open a level A support ticket with Professional Direct. They have responded, but all they did was open a ticket with DSE. I've received nothing from DSE that they are even looking at our problem. I need to make a rollback call and I don't even have a way to request a rollback. The comments section of the service request is complete worthless. My experience is that it is not monitored. When a service request is accepted, a resource with a name, email address and phone number need to be provided to the customer.