Factor sources — the locality rule
Stage IPAL § PF-3 says which column dispatches a factor's value and who answers it. This page says the constraint on where that answer may live — a rule about ownership and availability rather than about correctness, and the one the Configuration module refuses a product over.
Provenance and status. From the PC 9951 run on the Ablera dev database, 31.08.2026 (Product Configurator § SRC, full text in the extract) — except the product-population counts of § 4, which drift and are therefore a query at plan time rather than a figure on this page.
1. The rule
P ⚠ A pricing factor's source must resolve inside the Serdica schemas. A source that resolves through a database link to another system is not permitted in a product this module configures. Such a product cannot be priced or supported from here: its values live somewhere the module can neither read, write nor reason about, and a remote link is an availability and ownership dependency that configuration must not create.
F The table name does not tell you which you have. A source that looks like an ordinary table may not exist in Serdica at all — it may be a synonym over a link, or a name resolved inside PL/SQL and qualified with a link. Three questions settle it, and all three are asked before relying on any source: does the object exist locally; is there a synonym over a link with that name; and what links exist at all.
P So S1 emits every factor's named source, and S3 resolves each one locally before the factor is written. An unresolvable source is an unresolved[] entry against S1, never a guess — the same treatment as a missing value (Stage Normalization § WS-6).
2. Where it bites
F SRD_INTEGR.ABC_CFG_PRICING_FACTORS maps a pricing factor to where its value is read, and its sources resolve remotely. It also feeds a different premium pipeline from the browser quote path, so populating it does not help a quote — it only creates the dependency. A product configured by this module carries no rows there.
P That is the same boundary the reconciliation's C-4 draws from the other side: S2 owns ABC_CFG_* only where the specification says the product is priced from the INSIS side, and for an IPAL-only product the request map is deliberately empty and the acceptance script asserts it (Product Configurator § C). The locality rule is why the empty map is correct rather than merely permitted. Decided 04.09.2026 (D121): the map and the ABACUS-side validations are worked by a dedicated abacus–insis sub-agent of the Support module, which S2 consults for an INSIS-priced product.
F The local equivalent is PR_PRICING_FACTORS, whose source names stores that exist locally in SRD_CUST — the submitted-values store, the annex and cover-definition tables, and the object's own attribute columns (Stage IPAL § PF-3).
3. Pinning a constant is not a substitute
F ⚠ Setting a default in place of a blocked source makes the quote resolve and silently mis-prices every non-default choice the customer can select. It is the worst of the available outcomes: the product passes numeric verification against whichever example happens to use the default, and fails in production for every other selection.
P If a factor's only source would be remote, the factor cannot be rated from here — it is said so and recorded, not pinned. This is P-7 of Product Configurator § P applied to a source rather than to a value: an invented source, like an invented value, looks finished and prices wrongly.
4. Product populations — the shape of the estate
F There is no single product registry; a product's behaviour is decided in three independent places and what an operator can actually sell is the intersection — the catalogue (Stage IPAL), the tariff (Stage Abacus) and the packaging (Stage Offer). Counted over the estate, products fall into four buckets:
| Bucket | Meaning |
|---|---|
| tariff and catalogue | the real sellable set — priced by the engine, sellable in IPAL |
| tariff, no catalogue issuance | configured but not issuable — skip when mirroring |
| catalogue, no tariff version | issuable with no rating version — an anomaly, worth a ticket |
| issued outside IPAL | not sellable through IPAL (the PORTAL channel or INSIS Forms issued it) and not a model for an IPAL product |
P The practical use is a pre-check on a whole class of case: when a request says "configure product X like product Y", confirm Y is in the first bucket before copying anything from it. Counts drift, so this is a query at plan time, not a remembered list — and it is the same donor question Configuration Module § 5 asks about completeness, asked earlier and about fitness.
5. Ownership boundary
F A configuration row or a data fix needs no change request; code or a user exit does, and goes through the Development module (id source) process (Development Module).
P A recurring manual per-policy fix is a signal that a configuration cell is wrong. It is a configuration bug to escalate, not a workflow to automate — which is the test the Data and information module applies before a repeated shape becomes a skill (D144, Stage Precipitation).
Challenges
- C Whether the locality probe runs once per environment at connection time or per factor at plan time is open; the three queries are cheap enough for either, and the first case with a remote-sourced factor decides.
Related: Stage IPAL · Stage Abacus · Shared Vocabulary · Product Configurator § A