get_data() grouped only by Purchase Order Item while selecting Purchase
Order parent columns. MariaDB allows this loose GROUP BY; Postgres rejects
it with "column ... must appear in the GROUP BY clause".
Add the Purchase Order PK (po.name) to the GROUP BY. po.name is 1:1 with
the already-grouped po_item.name, so groups are unchanged and the result
is identical on MariaDB.
Adds a test (no test file existed) that runs the report and asserts the PO
is listed, exercising the GROUP BY on both engines.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Convert the MariaDB-only raw `frappe.db.sql` in the Selling and Buying
modules to the cross-database query builder / ORM, and fix the few
non-portable constructs that remain. Every change is a no-op on MariaDB
(identical rendered SQL / identical results) and only brings PostgreSQL —
which is standards-strict where MySQL is lax — in line.
Patterns addressed in these modules:
- Strict GROUP BY — PostgreSQL rejects SELECTing a non-aggregated column
that isn't functionally dependent on the grouped key. Sales Order
Analysis, Sales Analytics, Purchase Order Analysis and Procurement
Tracker now group by the PK (1:1 with the existing key, so no behaviour
change) or aggregate genuinely-independent columns.
- App clock vs DB clock — Sales Order Analysis computed delay against the
database CURRENT_DATE, which differs from the app's today by a day when
the DB runs a different timezone; switched to `nowdate()` (deterministic,
identical on both DBs).
- Portable date math / functions — DATEDIFF and friends via the db-aware
query-builder functions.
- Raw SQL → query builder for the remaining self-contained selling/buying
reads (POS item search, customer naming suffix, packing-items
availability, customer credit/acquisition reports).
Part of the staged MariaDB↔PostgreSQL parity rollout (module 1 of 9).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
