# How to set data selection and processing options in JD Edwards > Source: https://netray.co/erp-help/jde-data-selection-processing-options > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind how-to ## System jd-edwards ## Erp JD Edwards EnterpriseOne ## Module UBE Design / Versions ## Query how to set data selection and processing options in JD Edwards ## Alternate Queries - JDE version data selection tutorial - how do processing options work in EnterpriseOne - add data selection to JDE report version - JDE processing option template DSTMPL ## Applies To JD Edwards EnterpriseOne 9.1, 9.2, any report or interactive application version ## Steps ### Set data selection and processing options on a version **Items:** In Batch Versions (or the app's Version List), select your version and click Data Selection to open the filter builder. Build 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. Save 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. From the same Version Detail screen, click Processing Options to open the version's PO template. Fill 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. Save and, if prompted, confirm which processing option template revision you are saving against, since template changes can require re-saving existing versions. Run 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. For 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. ## Sections ### Data selection: filtering the rows **Body:** 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 **Body:** 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 **Body:** 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. **Code:** -- Roughly what data selection compiles to underneath SELECT * FROM businessview WHERE BusinessUnit = '30' AND (DocumentType = 'SO' OR DocumentType = 'SC') AND OrderDate >= @RuntimeDate ## 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. ## Ai Angle 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. ## Faq ### Are data selection values stored per version or shared globally? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms JDE data selection tutorial, JD Edwards processing options, EnterpriseOne version setup, JDE UBE data selection vs processing options, DSTMPL processing option template, F9210 F9211 data selection tables, how to filter JDE report data, JDE version detail configuration --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json