How to set data selection and processing options in JD Edwards
how to set data selection and processing options in JD Edwards
Also searched as
- JDE version data selection tutorial
- how do processing options work in EnterpriseOne
- add data selection to JDE report version
- JDE processing option template DSTMPL
Short answer
Data selection controls which rows a UBE's underlying business view reads (a filter, stored per version in F9210/F9211), while processing options control how the program behaves once it has that data (a settings template stored per version in F983051/F983052). They are configured from the same Version Detail screen but are separate, unrelated mechanisms that new users routinely confuse.
Applies to: JD Edwards EnterpriseOne 9.1, 9.2, any report or interactive application version
Set data selection and processing options on a version
- 1In Batch Versions (or the app's Version List), select your version and click Data Selection to open the filter builder.
- 2Build conditions against the business view's columns using AND/OR logic, literal values, UDCs, or runtime placeholder values (e.g. system date, current user) as needed.
- 3Save the data selection - it is stored per version, so copying a version copies its selection as a starting point, not a live link back to the original.
- 4From the same Version Detail screen, click Processing Options to open the version's PO template.
- 5Fill in each tab's fields - these map directly to the fields defined in the report's or application's processing option template (DSTMPL) in design, not to the business view at all.
- 6Save and, if prompted, confirm which processing option template revision you are saving against, since template changes can require re-saving existing versions.
- 7Run the version and confirm the row count and output match your intended data selection, then confirm the behavior (e.g. summarized vs detailed printing) matches your processing option choices.
- 8For versions driven by external triggers (subsystem, scheduler, orchestration), double check the correct version name is referenced, since data selection and processing options are meaningless if the wrong version gets submitted.
Data selection: filtering the rows
Data selection is a WHERE-clause builder against the version's primary business view. Each line is a column, an operator, and a value, which can be a literal, a UDC (user defined code), a processing option value passed through, or a system runtime value like *TODAY or the logged-in user.
Complex selection needs parentheses/grouping for correct AND/OR precedence - a common mistake is stacking conditions flat and getting an unintended OR across the whole set rather than a grouped condition.
Processing options: controlling behavior
Processing options are a settings form defined by the developer in the report's or application's design (as a DSTMPL - data structure template), with tabs and fields that map to variables the RPG-style event rules or named event rules logic reads at runtime.
They do not filter data by themselves - they control things like which mode a report runs in (summary vs detail), which version of a sub-called program to invoke, default values for related applications, or which glossary text/date range to apply inside the program's own logic.
How they interact in practice
A single version pulls both together: data selection determines the rows fetched from the business view, and processing options determine how those rows are then processed, formatted, or which downstream calls fire. Changing only the processing options will not change which rows are pulled, and changing only data selection will not change formatting or downstream calls.
This distinction matters most when troubleshooting 'wrong report output' - first confirm whether the issue is which rows appeared (data selection) versus how those rows were handled (processing options), since fixing the wrong one wastes a support cycle.
-- Roughly what data selection compiles to underneath SELECT * FROM businessview WHERE BusinessUnit = '30' AND (DocumentType = 'SO' OR DocumentType = 'SC') AND OrderDate >= @RuntimeDate
Common pitfalls
- !Confusing data selection with processing options when troubleshooting - they are configured on the same screen but solve entirely different problems.
- !Flat-stacking AND/OR conditions in data selection without grouping, producing unexpected row sets.
- !Editing a processing option template's underlying design (DSTMPL) without realizing every version using that template needs review, since existing saved values do not automatically map to newly added fields.
- !Copying a version and assuming data selection changes on the copy affect the original - each version's selection is independent once copied.
- !Using a UDC value in data selection that later gets renamed or removed, silently changing what rows a long-running version returns.
How an ERP-grounded AI assistant handles this
ERPray can read a version's stored data selection and processing option values and explain in plain language what rows it will pull and how it will behave, which is faster than opening Version Detail and mentally reconstructing grouped AND/OR logic. It is most useful for auditing existing versions before you change them, not a replacement for actually testing the version after an edit.
Frequently asked questions
Are data selection values stored per version or shared globally?
Per version, stored in tables like F9210/F9211. Copying a version copies the current selection as a starting point, but the copy is fully independent afterward.
Can processing options reference the value chosen in data selection?
No, not directly - they are separate mechanisms. A processing option value can be used inside data selection as a runtime placeholder, but data selection results do not flow back into processing option fields.
What happens if I add a new processing option field to a template after versions already exist?
Existing versions will show the new field with a blank or default value until someone opens and saves that version's processing options again; the version does not automatically pick up a sensible default without review.
Can data selection use a value passed in from an orchestration or external caller?
Yes, if the version's data selection is built against a processing option or runtime value that the caller can set (for example via an orchestration's parameter mapping), rather than a hardcoded literal.
Related
How to set up JD Edwards Orchestrator (step by step)
An EnterpriseOne orchestration chains one or more requests (form requests that drive an interactive application, or service requests that call a BSFN, business service, or SQL) plus optional rules and notifications, then exposes the whole thing as a callable REST endpoint via the AIS (Application Interface Services) server. The setup work happens in Orchestrator Studio, not the Fat Client.
Error fixJDE UBE failed (status E): how to read jde.log and jdedebug.log
A UBE (batch report/program) that ends with status E in Work With Submitted Jobs tells you almost nothing on its own. The real error is in jde.log on the enterprise server, in the job's own PDF/log subdirectory (jdedebug.log if you turned on debug), and in the work directory for that job number under PrintQueue or the OS temp path.
Error fixJD Edwards business function (BSFN) errors: how to diagnose them
A BSFN error in EnterpriseOne means either the compiled function was not found for the current package build, or the function ran and threw an internal exception (often a null business view row, an unhandled C runtime error, or a failed table I/O). The fix path is different for each, so the first step is always determining which one you are facing from jde.log.
Error fixJD Edwards: record is being used by another user (record reservation)
EnterpriseOne places a soft record reservation lock when a user opens a record for edit, tracked in the F00165 table, and releases it when the user saves, cancels, or the session ends cleanly. A stuck lock almost always means a session died abnormally (browser crash, network drop, kiosk timeout) without triggering the release, and it must be cleared by an admin, not by the original user retrying.
Error fixJDE package build failed: how to find the real cause
A package build (Full or Update) that ends in a failed or errored status on the deployment server does not explain itself in the Package Build Workbench screen. The real diagnostic detail is in the package's own log subdirectory on the deployment server, which holds a build log, a table conversion log, and per-object compile logs that pinpoint the actual failure.
How-toJD Edwards table conversion: how it works and how to run one
Table conversion (TC) is the EnterpriseOne mechanism that updates a table's physical structure and converts its existing data whenever a table's definition changes in Object Librarian, most commonly running automatically as part of a package build. Simple field additions or size changes convert automatically; more complex changes such as splitting a field or transforming values need a custom conversion routine attached to the table object.
AI for ERPAI for JD Edwards EnterpriseOne, Built on Orchestrator and AIS
Add AI to JD Edwards E1 9.2 using Orchestrator, AIS, and BSSV rather than screen-scraping. Ground a private LLM on F4211, F4111, and F0411 data.
Stuck on JD Edwards EnterpriseOne?
Talk to engineers who work inside JD Edwards EnterpriseOne every week, and who build private AI that answers these questions from your own ERP data.