A malicious actor can store and distribute malicious files on D365. Also, an attacker might be able to upload malicious executables or malicious documents and execute commands in the victim user's browser, including operations in the application on behalf of the victim user or exfiltrating sensitive information, such as a session identifier. 

Please consider applying the following constraint regarding the file upload functionality:

• Malware scanning should be implemented on all uploaded files. 

This is a continuation of these ideas:

https://experience.dynamics.com/ideas/idea/?ideaid=2f765bc9-7cfc-e911-b862-0003ff68ac6b

https://experience.dynamics.com/ideas/idea/?ideaid=6964e78c-a4d9-e711-80c0-00155d7cd0b4

The functionality for generating files for customer reimbursment was recently added to MS Dynamics 365, version 10.0.36.

While we can generate an outbound pain.001 (CustomerCreditTransferInitiation) file, we are still missing the functionality for importing the return files from the bank. This includes both pain.002 (CustomerPaymentStatusReport), and cmt.054 (BankToCustomerDebitCreditNotification) files.

The functionality for importing return files should be included in the sollution.

Currently, consolidate online does not appear to have functionality to correctly convert balance sheet accounts.

Under IAS 19 balance sheet accounts should be revalued from foreign currency at the closing date. Consolidate online revalues the movement in the period to this date, however it will ignore the opening balance, thus the total closing balance is always converted incorrectly. In large non-current accounts, this can lead to quite big differences!

I would suggest that consolidate online functionality be designed so that it can correctly convert balance sheet FX.

If you use centralised payments across company for vendor payment and use a method of payment which uses a bridging account you can only settle the bridged transactions if you create the vendor account in the payment company.

A dimension attribute error is return unless the vendor is also in the payment company.

Unable to return DimensionAttributeValue record for dimension SystemGeneratedAttributeVendor with value SP000005, in legal entity w093, because a record doesn't exist in table VendTable through view DimAttributeVendTable.

The vendors are not used for any other purpose in the payment company except to make the payment and therefore this adds considerable data migration effort (especially when 50+ companies and many thousands of vendors). Ongoing maintenance is also required for new vendors and process wise always have to ensure created in invoice company and repeated in payment company.

It contradicts the purpose of centralised payments and intercompany account that you have to duplicate the party id just to settle a bridged transaction.

Currently, deferral journals generated via Subscription Billing for procurement scenarios do not support Financial tags, limiting traceability and reporting capabilities. We request that Financial tags be supported in these deferral journals, aligning with their availability in other modules like purchase order invoicing.

On an approved or confirmed purchase order, it is noticed that if we make a Request Change that edit the unit price, the PO will need to be re-approved through workflow and re-confirmed. Upon reconfirmation, a new record would be generated in "Purchase order confirmation" (001).

Now, if we make a Request Change but instead only make a change on header (method of payment for example), i's noticed that the PO will be automatically approved and confirmed. This request change, however, does not generate a new Purchase order confirmation record.

However, if we make a third Request change which requires re-approve and re-confirm again (similar to request change number 1), it will be noticed that the new record's number will skip number 002 and show up as 003 instead.

It appears that despite not generating a new record on Purchase Order Confirmation, request change number 2 would still be counted.

Cause:

When we confirm a PO, the PO confirmation journal number is created according to the count of purchase order version:

VendPurchOrderJour::setDocNum(): this.PurchOrderDocNum = strFmt('%1-%2', this.PurchId, VendPurchOrderJour::numberOfPurchaseOrderVersions(source));

When a PO was approved automatically by workflow, it will also be confirmed automatically, and no confirmation journal will be created. However, a purchase order version will still be created.

Thus, upon the next confirmation, the system will still take count the auto confirmation, leading to the Document Number on VendPurchOrderJour showing 3 instead of 2

Suggestion:

For better consistency, request changes which trigger auto approval/confirmation should either generate a confirmation journal or should not be counted upon the generation of new confirmation journal DocNumber

Our client raised a bug where they set Bank module access to for a particular calendar month expecting that it will prevent users from posting/reconciling or performing other actions in the Bank ledger during the Period-end process. The client was surprised to learn that users were able to carry on performing their day to day tasks despite Bank module being closed.

We tied to find any official documentation, which would specify restricted activities when each sub-ledger access is set to None, but there was nothing available.

When we raised a ticket with Microsoft and were told the following "When status is set to It only blocks posting to GL during bank reconciliation. Bank reconciliation will not post any voucher to GL if there is no adjustment or new transaction".

The above explanation from Microsoft indicates that the remit of the Ledger calendars module access functionality is very limited and to some extent counter intuitive, because users would at least expect to be prevented from posting payments(AR/AP) to bank ledger when the Bank module access is set to None.

After discovering that setting Bank module access to did not prevent them from doing their daily activities, our Client started to feel nervous about using the Ledger calendars to restrict access to sub-ledgers during Period end, because they were not sure what restrictions users would have.

Microsoft need to provide documentation where they will details what activities and transactions are restricted when each sub-ledger access is set to None.

Croatian language support is currently missing in Dynamics 365 Finance & Operations. Its inclusion is highly requested for improved user accessibility and localization.

Complemento de ICMS-ST e processo de declaração e restituição para o estado do Paraná (PR).

Atualmente a funcionalidade já existe para outros estados, como RS, SC e SP. Gostaríamos que a funcionalidade de restituição para o estado do Paraná também fosse implementada, pois a sede da nossa empresa é nesse estado.

A empresa está deixando de restituir um volume considerável pois atualmente o produto padrão não possui a funcionalidade, impactando na precificação do itens e no lucro da empresa.

Para saber mais sobre a funcionalidade implementada para os outros estados: https://learn.microsoft.com/pt-br/dynamics365/finance/localizations/brazil/latam-bra-complement-restitution

Para ler a documentação para o estado do Paraná: https://www.fazenda.pr.gov.br/sites/default/arquivos_restritos/files/documento/2020-10/Manual_ADRC_ST_versao_1_2.pdf

Obrigada

Autogiro is used for direct debet payment and we would like to update the payment journal lines with a confirmation of bank payments executed, based on the ISO20022 Camt.054C format. By matching the paymentID to existing payment lines it should be possible to distinguish between existing Autogiro lines and new customer payments.This should be done by importing the Camt.054C file into the Payment transfers page similar to this Swedish functionality:

"Bankgirot Autogiro returns format for the direct debit payment format of the same name. These messages can be imported as a response to direct debit messages that were previously exported. Currently, these payments are represented in Operations as payment journal lines with a Sent status. To import a file, complete the following steps.

Go to the Payment transfers page.

Click Return file-customer.

In the dialog box, select corresponding method of payment, and then browse to the location of the file to import.

After you import the return file, the payments should be updated to the status Approved."