docs: describe the PC0030 setup and reference table exception

content/docs/analyzers/PlatformCop/PC0030.md

@@ -63,6 +63,21 @@ The diagnostic is not reported when:
 - The variable is passed as an argument to any function, event, or `PAGE.Run`/`PAGE.RunModal`
 - The variable is a temporary record
 - The variable is a global or parameter variable — only local variables are analyzed
+- The table is a setup or reference table (see below)
+
+### Setup and reference tables
+
+Partial records interact with the server's record cache in a way that can make `SetLoadFields` slower, not faster. When a full record is read, the NST keeps it in its record cache, and a repeated identical read is served from memory without a SQL round trip. A partial-record read bypasses that cache: every repetition goes back to SQL Server. On a table with a handful of rows that is read constantly — a setup singleton, a posting group, a payment term — the cache is essentially always hot, so loading fewer columns saves nothing while losing the cache hit.
+
+The rule therefore does not report any read operation on a local variable whose table is recognized as a setup or reference table. The recognition is structural, so it applies equally to Microsoft, partner and localized apps:
+
+- The table's namespace ends with `.Setup` (for example `Microsoft.Finance.GeneralLedger.Setup`, home of `Gen. Product Posting Group` and `General Posting Setup`).
+- The primary key is a single `Code` field named `Code` or `Name` — the shape of posting groups, payment terms, currencies, locations, units of measure, dimensions and journal templates.
+- The primary key is a single `Code` field named `Primary Key`, or the table declares a parameterless `GetRecordOnce` procedure — the shape of setup singletons such as `General Ledger Setup`.
+
+A table whose primary key is an `AutoIncrement` field is never treated as a reference table, even inside a `.Setup` namespace: an auto-incrementing key marks a growing table.
+
+Master data (`Customer`, `Vendor`, `Item`), documents and ledgers are still reported. Whether a specific read on those tables benefits more from partial records or from the record cache depends on the data volume and how often the same record is re-read — information the analyzer does not have. Treat PC0030 there as the suggestion it is, and measure when in doubt.
 
 ### Local variables only
 
@@ -101,6 +116,7 @@ Together they provide full coverage: PC0030 encourages adopting partial records,
 - [Record.SetLoadFields](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/record/record-setloadfields-method) on Microsoft Learn
 - [RecordRef.SetLoadFields](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/recordref/recordref-setloadfields-method) on Microsoft Learn
 - [SetLoadFields best practices](https://alguidelines.dev/docs/bestpractices/setloadfields/) on ALGuidelines.dev
+- [Partial record vs NST caching: the strange case of Calculate Low-Level Code](https://duiliotacconi.com/2026/09/07/partial-record-vs-nst-caching-the-strange-case-of-calculate-low-level-code/) by Duilio Tacconi
 - [Partial Records in detail (part 1)](https://bccaptain.com.au/2020/11/27/partial-records-in-detail-part-1/) by Tomas Kapitan
 - [Partial Records in detail (part 2)](https://bccaptain.com.au/2020/12/29/partial-records-in-detail-part-2/) by Tomas Kapitan
 - [SetLoadFields with reference and value passing](https://demiliani.com/2021/06/03/dynamics-365-business-central-setloadfields-performances-with-reference-passing-or-value-passing-parameters/) by Stefano Demiliani