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

When a company within EU sell to a customer who does not have a valid VAT registration, the transactions cannot use intracommunity VAT calculation. Domestic VAT must be calculated instead.

In principle a company must validate that the VAT registration is valid every time the company sell to an EU customer to avoid calculating domestic VAT.

Since this is a manual procedure, this is often not done. Instead we need this to be automated,

The European Commission have create a website where it is possible manually to validate if a VAT registration is valid or not.

Wen site is called "VIES VAT number validation"

Idea: a functionality in D365FO that can be set up to on a daily basis to make that check for all VAT registrations in the Tax exempt number table.

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."

Create Posting profile.

Create 2nd posting profile for Default.

While doing customer payment journal we will select one posting profile and we will post it, later we will do the reimbursement for the same customer at this time it is considering the default customer posting profile. where there are two different accounts are mapped.

Accounts Receivable>> Payments>> Customer Payments.

Click on new and update Cust pay and go to lines.

Update the customer account and credit amount and select offset account type ledger and offset account cash payment.

Go to Payment tab and update posting profile is PR and save.

Post the customer payment.

Reimbursement

Accounts receivable >> Periodic tasks >> click on Reimbursement.

In reimbursement parameters page, select include customer with outstanding, filter with customer account.” customer” click on ok. Reimbursement process will complete.

• Accounts Receivable -- >Inquiries and reports-- >Customer-- > Customer to Ledger reconciliation.

• Generate report.

1.Example: Select any month data or small set of date (from date:10/9/2023 and to

date :10/10/2023) with include details option.

2.Select Include details option.

3.click on ok.

While generating the customer to ledger reconciliation report, when there is both customer balance and ledger balance in the report difference column is working fine, when there is no customer balance but there is a ledger balance in the report in this scenario also there is a value in difference column but when there is a customer balance but there is no ledger balance in the report in this scenario there is no value in the difference column.

Actual

Results:

While selecting include details option under customer to ledger reconciliation report unable to see accurate values and system shows zero difference on customer to ledger reconciliation report.

ACTUAL: Select any Example: Voucher number”00004”

Customer balance: 4,000

Ledger balance: 0.00

Difference: 0.00

Expected

Results:

While selecting include details option under customer to ledger reconciliation report, system should show correct difference values on customer to ledger reconciliation report.

Expected: Select any Example: Voucher number”00004”

Customer balance: 4,000

Ledger balance: 0.00

Difference: 4,000

Please fix the Report issue in the customer to ledger reconciliation report.

The drill-down links feature functions only within the PDF Viewer, which means it will only work when the link is clicked within the report generated on screen, and it will open the specific record in the current page.

It should work also if clicked to open on a new tab or if the report is exported to a pdf file or excel file. It would be very useful for the users and make them everyday work easier as a result.

Customers may have legal entities registered in countries such as Germany and be tax registered in Hungary which is available for multiple tax registration however the RITR facility requires the customers legal entity to be based in Hungary to work and requires customisation to be made available.

To be consistent with the MTR functionality - features such as RITR should be made globally available

When generating a purchase order for a fixed asset, where more than one line linked to the same fixed asset is entered, the system is computing for PIS and COFINS purposes only the first line linked to this fixed asset and ignoring that there are more lines in the same order linked to that asset.

For example:

Purchase order: OCxxxxx

1. Item number: BRMF710 - Fixed asset number - BRMF999999 - amount = 985.00
2. Item number: BRMF800 - Fixed asset number - BRMF999999 - amount = 500.00
3. Item number: BRMF900 - Fixed asset number - BRMF999999 - amount = 128.00

Fiscal Books > All PIS and COFINS fixed assets > created 3 lines, but

Created BRMF999999-1 - Amount - 985.00

Created BRMF999999-2 - Amount - 985.00

Created BRMF999999-3 - Amount - 985.00

Hey Guys

Issue we are facing is multiple finance people are settling vendor or customer transactions at the same time.

Employee A open vendor settlement from the Vendor form and select multiple transactions

Employee B open vendor settlement on the same Vendor.

No indications that user A already has marked transactions, these is just marked as as normal.

Employee B start to select transactions, and employee A select settle. The transactions employee B has done and not finalized in the process is getting settled by employee A, so many partially settled. An now updated that Employee A has settled all transactions, but is Employee B which had marked the transaction and is not finalized in the process.

An indication like marked transactions from a General journal or other journal will help so employees not settle unexpected transactions.

Issue Description:

When using the Post button on the Consolidated invoices for Japan page, a general journal entry is created and posted. However, the journal name used in this process cannot have approval and workflows configured. If such settings are applied, an error occurs when clicking Post button on the consolidated invoice page.

As a result, it is not possible to prevent a malicious user from using the journal name on the general journal page to post journal entries without any approval.

Request:

Please fix this so that malicious users cannot post journal entries using the posting function on Consolidated Invoices for Japan page without anyone's approval.