Microsoft Dynamics 365 Business Central Self-Help Place

If you have tried to post a sales credit memo or sales invoice and been stopped by the message below. It is one of the posting errors due to data issue on the document itself, not a system fault. There is no Cust. Ledger Entry within the filter. Filters: Customer No.: xxx, Document Type: Credit Memo / Invoice, Document No.: xxx, Open: Yes What Business Central is actually telling you When a sales document has Applies-to Doc. Type and Applies-to Doc. No. filled in, Business Central tries to apply the new entry against that existing customer ledger entry as part of posting. To do that, it searches Customer Ledger Entries using the filters shown in the error. If no entry matches every filter, posting stops. So if you are posting a credit memo and the error says Document Type: Credit Memo , your credit memo is set to apply against another credit memo. That is almost always a sign the application fields are wrong. Common causes The target entry is already closed. The i...

This is probably the question I get most from new Business Central users: "I forgot to print the Test Report before I posted my General Journal. Where can I reprint it?" Most finance teams print the Test Report and file it as their Journal Voucher . Usually nobody looks at it again — until the auditor picks a high-value adjustment and asks for the supporting voucher. You just need to print it from a different place: the G/L Register . Why You Can't Reprint the Test Report The Test Report only reads the lines that are still sitting in the journal , waiting to be posted. Once you click Post, Business Central moves those lines into the General Ledger and clears the journal. So after posting, there is nothing left for the Test Report to print. What Business Central does keep is a record of every posting run. Each time you post, BC creates one line in the G/L Registers page, with a running number, who posted it, when, and which journal batch it came from. That re...

In Business Central the purchase cycle produces three separate records. Together they are your three-way match . Purchase Order What we agreed to buy Posted Purchase Receipt What we actually received Posted Purchase Invoice What the vendor billed us Finance signs off on the invoice because the receipt proves the goods or service arrived, and the order proves the price was agreed beforehand. This post walks through one full cycle end to end, using a partial delivery, and finishes with the part everyone gets wrong — cancelling the small balance that will never arrive. The scenario We are buying a service — a purchase line of type G/L Account rather than a stocked item. This is very common for marketing, printing, subcontract labour and professional fees. Quantity 100 × RM 25.00 = RM 2,500.00 Delivery happens in stages: 80 first, then 15 , and the last 5 are cancelled by mutual agreement. Order 100 Receipt 1 80 Invoice 1 80...

This page is a running reference for the errors that come up most often in Microsoft Dynamics GP → Sales Transaction Entry ( Transactions >> Sales >> Sales Transaction Entry ). Each section lists the exact message you will see on screen, why GP raises it, and the steps to clear it. Find your message in the list below and jump straight to it. Jump to an issue One or more line items contain warnings or errors. / Distribution account(s) are missing or invalid The accounts receivable distribution(s) does not equal the actual amount Account is empty. Do you want to save changes with errors? Tax codes are not showing Issue 1 — One or more line items contain warnings or errors What you see One or more line items contain warnings or errors. On the edit list or when you click the warning icon beside the line, the detail reads: Distribution account(s) are missing or invalid. ERROR: Line accounts are missing or invalid. A small warning symbol appears again...

Symptom: You post a Cash Receipt Journal in a foreign currency, key in the actual bank rate directly on the line, and the receipt posts correctly. Then you apply that receipt to the customer's invoice (recorded in Local Currency) — and Business Central posts a forex gain/loss that shouldn't be there at all. It looks like the customer paid more (or less) than what actually landed in the bank. The scenario Local Currency (LCY): GBP Invoice: GBP 1,000 Customer pays: USD 1,346.39 — the bank-negotiated rate that day meant this USD amount exactly covers the GBP 1,000 invoice, no more, no less. Expected result: Payment = Invoice. Applying the receipt should close the invoice with zero forex gain/loss. What actually happens: after applying, Business Central posts a gain or loss anyway, and the receipt's own Amount (LCY) changes in the process. Why this happens You post the Cash Receipt Journal with Currency Code = USD, and use Change Exchange Rate (the Assist...