• Functionality to define expected scrap value for fixed asset in percentage.

    Presently, the expected scrap value for a fixed asset can be defined as an absolute amount and not in percentage terms. However, this is tedious as it requires manual calculation and is also prone to human error.


    The expectation is to have the functionality to define the expected scrap value in percentage terms so that the system can calculate the expected scrap value in amount terms automatically and update it on the fixed asset record.

  • India GST - When 'Post physical sales tax' parameter is enabled in Inventory management parameters, GST recorded on Purchase order product receipt does not get reversed on Product receipt cancellation.

    When the 'Post physical sales tax' parameter is enabled in Inventory management and accounting parameters, GST gets recorded on Purchase order product receipt posting.

    However, if product receipt is cancelled, the GST recorded on product receipt is not getting reversed.

    The expectation is that GST recorded on Product receipt should be reversed and accounted for on cancellation of Product receipt.

  • The rate per mile gets rounded up to the nearest decimal and hence shows incorrect mileage rate on the expense report line

    In expense management, system allows the mileage rate to be defined up to three decimal places. However, the 'Rate per mile' on the expense report line is the average of the rate that is appliable for expense line in case of multiple tiers applicable. It is not the amount fetched from the rate master.


    To explain this with an example, let's say that the rate per mile defined on the Mileage rate tiers is 0.529 per mile. On the expense line, the user enters 4 miles. In this case, the calculation will be done as follows:

    Transaction amount for expense line will be calculated as Rate per mile * no. of miles i.e. (0.529*4) = 2.12 after rounding; and

    Rate per mile will be calculated as Net amount/No. of miles i.e. 2.12/4 = 0.53

    As a result, the 'Rate per mile' field on the expense report line will display 0.530 instead of 0.529 (which is the rate defined in the master). This gives an impression to the user that the 'Rate per mile' as defined in the master is not used by the system for calculating the expense line amount and a random rate is picked up by the system for doing the calculation.

    This behaviour needs to be corrected. 'Rate per mile' should always show the correct rate as defined in the 'Mileage rates' master per the applicable tier.

  • Need to have a direct relationship between the Captured invoices table and Received files table

    Presently, in the Invoice capture solution, there is no direct relationship between the Captured invoices table and Received files table. It will be really helpful to have a relationship between these two tables as this will help the customers to create more meaningful/user friendly views in the 'Captured invoices' view.

  • The cost price should get updated on the Project item journal line when added using Excel add-in

    The user is adding lines to the Project item journal using the Excel add-in. However, presently, the cost price for the line is not getting updated automatically and is populate as 0.00 on publishing the data using Excel add-in. However, when the line is created manually on the Project item journal form, the cost price is updated correctly.

    The cost price for the line should be updated on the Project item journal when the line is added using Excel add-in.

  • Limiting company data into Financial Reporter

    Presently, it is not feasible to sync data related to only some specific legal entities in MRDB. If the customer would like to use the MR/FR only for some specific legal entities out of all the Legal entities that they have on their environment, the system should provide the option/functionality to choose the legal for which the data will sync to MRDB.

    This will enable the customer to reduce the database size of the MRDB based on their business need. 

  • Values in the Credit limit and Credit available fields on the Customer account statement should be in Customer currency

    The values in the 'Credit limit' and 'Credit available' fields on the Customer account statement should be in Customer currency.

    Report path: Accounts receivable > Inquiries and reports > Customers > Customer account statement


    Presently, the values in the fields ‘Credit limit’ and ‘Credit available’ on the Account statement report are in accounting currency of the legal entity.

    However, since Customer account statement is an external document, the expectation is that the values in both these fields should be in customer currency. Due to the existing behaviour, the customer cannot see the credit limit and the credit available amount in their currency.

  • IND GST - Need the functionality to record GST in customer prepayment invoice

    The functionality to create Customer prepayment invoices is available in the product. As per the GST law in India, GST needs to be recorded on such customer prepayment invoice. Presently, the system includes the GST amount on the Sales order for calculating the Prepayment invoice amount, but such GST amount is not recorded as GST payable in the system i.e. GST is not recorded separately but is grossed up in the prepayment invoice amount.

    However, the requirement is to record the GST amount on customer prepayment invoice separately as GST payable.

  • PO header workflow should also evaluate the 'Budget check not performed’ condition for auto rejection action.

    The customer is using the PO approval workflow. They have a scenario where the PO should be routed to the approver only if the budget check result for all the PO lines is passed.

    We have tried catering to this scenario by using automatic action on PO header workflow as follows:

    If any of the PO line has either of the following statues, the work item should be automatically rejected:

    Budget check not performed for any of the PO lines; or

    Budget check passed but with warning for any of the PO lines; or

    Budget check failed for any of the PO lines.


    We have tried using the ‘Purchase orders. Budget check results for document’ condition to achieve the desired result.

    However, we have noted that the condition ‘Purchase orders. Budget check results for document is value Budget check not performed’ is not evaluated by the system and the PO is routed to the approver/s for approval even though the budget check is not yet performed on PO line/s.


    The ask is that the system should analyze the ‘Purchase orders. Budget check results for document is value Budget check not performed’ condition and should take the automatic action (of auto rejecting the workflow) as setup in Automatic actions section of the Approve PO workflow.