Marco Pham

When an importer (D365 customer) imports goods to Singapore, the GST (Goods and Service Tax) must be paid to the Tax Authority, 2 scenarios regarding the GST payment:

1. GST is paid indirectly by courier (CNF agent) on behalf of the importer.
2. GST is paid directly to the Tax authority by importer.

Currently the system does not fully support the automatic process for recording such GST transaction, we would have to carry out the following procedures:

1. For CNF GST payment, we would need to use the landed cost function to fully record all the charges (Tax, Goods, ...) and amounts for involved parties.
2. For direct payment, customer would need to use a workaround, which involved creating a minimum amount expense line in a journal which contains the Actual Sales tax amount, and later reverse the expense to keep the Sales tax, which is very inconvenient given that in large companies this process is carried out at an accelerated rate.

Going the given route Customer must edit the amount manually with a lot of steps and adjustment, it is demanded that the functionality should be possible for this to be calculated automatically and posted with least amount of manual intervention.

We requested that a functionality be made for customer/importer to be able to input, calculate, post and journal the GST and related amounts automatically at Purchase Order creation, at the same time suiting the scenarios mentioned above.

In the current design of the electronic document submission log for batch submission scenarios, users must navigate into each batch to view key details. To improve usability and efficiency, we propose adding two new columns to the submission log view:

• Total Invoice Amount: Displays the aggregated value of all invoices submitted in the batch.
• Store/Warehouse Origin: Identifies the originating store or warehouse for each batch.

Given that each batch typically corresponds to a specific store or warehouse in retail operations, this enhancement would provide immediate visibility into critical data without requiring additional clicks. It would significantly reduce the time spent on manual lookups and streamline the monitoring process.

This improvement would enhance the overall efficiency of the product and deliver measurable time savings for end users.

The Revenue Project ID field (Project management and accounting → All projects → Project → Revenue recognition) is designed to give flexibility in how revenue is recognized. When several sub‑projects roll up under a parent project, assigning the parent’s Revenue Project ID to each sub‑project allows the system to combine revenue recognition entries across all those related projects.

If each sub‑project uses its own Revenue Project ID, running revenue recognition will consume only one number from the voucher number sequence.

However, when multiple projects share the same Revenue Project ID, the revenue recognition process consumes voucher numbers based on the number of projects included under that Revenue Project ID.

Example:

If the current voucher number is PPV_0015, and you have 15 sub‑projects all mapped to the same parent Revenue Project ID, posting revenue recognition will generate vouchers up to PPV_0030.

It would be very helpful if the system provided a way to track which voucher numbers were consumed during this process, or an option to prevent this kind of voucher number “skipping” from occurring.