Skip to main content

BPAS

+91 98404 81581 Contact Us Contact Us
+91 98404 81581 Contact Us
+91 98404 81581

Table Designer

Perfion PIM · Complete Feature Guide

Table Designer Perfion Product Table Guide

Build each product table once and let Perfion fill it: one design, fed by the items where it is used, showing only the features that hold values, styled from one stylesheet and rendered into reports and the InBetween export.

See It for Your Tables What this guide covers

A Table feature in Perfion holds a table design and the queries that feed it. Its primary query reads the items where the table is used, so each category or product gets rows of its own. The table is laid out in Sets, each cell projecting values in a direction, and a dynamic cell adds only the features that hold values. Rows and columns collapse when they are empty, a stylesheet gives every table one look, and the PerfionTable control shows the result in reports.

Written for product data, catalogue and marketing teams · By , Founder and Solution Architect · Last updated BPAS · Exclusive Boyum Practice. India's No.1 Customer-referred Boyum IT Partner.

At a glance

Perfion name
Table features, the Table Designer, dynamic features and table styling
Where
Table features on catalogue categories or products, designed in the Table DesignerTable DesignerStylesheetsReportsThe table module is available under licence
Used by
Product data, catalogue and marketing teams, and report designersRendered tables feed internal reports and the InBetween export
Works with
Table feature typeConfigurationsCategorizers
Four cell types
Four documented cell types lay out every tableStaticValueDynamicCrossed
How It Works

How Perfion builds tables, from one design to every table

A table is designed once, pointed at the data, and laid out in Sets. Each place it is used gets rows of its own, and the rendered table goes into reports and exports.

  1. Create the table

    A Table feature holds the table design and the queries that feed it. It is selectable, so one design can be used on many categories or products.

  2. Point it at the data

    The primary query reads the items where the table is used, or the items related to them, so each place gets results of its own.

  3. Lay out the Sets

    Cells project Sets down or across, each column narrowed by the one to its left, and a dynamic cell adds only the features that hold values.

  4. Style it once

    Named styles from a stylesheet pass down from the table to its cells, with overrides only where a cell needs its own look.

  5. Render it for reports and exports

    The rendered table appears in internal reports through the PerfionTable control, and in the InBetween export as Table XML.

An illustration, not a screenshot: the data sources and feature list, a design with Static, Dynamic and Value cells, and the table it renders.
Typed Tables vs Perfion Tables

Typed tables vs Perfion tables: what changes when tables are built from data

Typed tables are copies of the product data, made by hand for each document. Perfion tables are designed once and filled from the product data each time they are rendered.

Tables typed into catalogue files and spreadsheets compared with Perfion's Table features, Table Designer, dynamic features, collapse, table styling and tables in internal reporting and the InBetween export, as described in Boyum IT Solutions' Perfion documentation.
Task Tables typed in documents and spreadsheets Perfion Table features and the Table Designer
Where tables are built In catalogue files and spreadsheets, one for each family. In a Table feature, designed once and reused.
Rows for each family Typed or pasted, model by model. Built from the items where the table is used.
When a specification changes Retyped in every table that shows it. In the table the next time it is rendered.
Families with different specifications A layout for each family, or columns left empty. A dynamic cell shows only the features that hold values.
Empty rows and columns Printed as dashes, or deleted by hand. Removed from the output by collapse.
Formatting Applied by hand, table by table. Named styles passed down from the table to every cell.
Long tables Headings retyped at the top of each page. Header rows repeated on each new page in internal reports.
Publishing tools Tables rebuilt in each tool. Delivered in the InBetween export as Table XML.

See how your own specification tables would be designed once and filled from Perfion.

See it for your tables
Capabilities in Depth

Perfion Table Designer capabilities: eight ways to build tables from product data

Each capability shows what it does in Perfion and what it is worth to the business.

Operational Reality (Capabilities)

A Table in Perfion is a feature that holds a table design and a set of queries. The queries produce data which, applied to the design, becomes a table of formatted information. A Table feature is selectable by default, so one design is reused across the system. It is added to a configuration like any other feature: on a categorizer such as a catalogue, for a table that covers many products, or on a product, for finer control. The table module is available under licence.

  • A design and its queries in one feature
  • Selectable, so reused across the system
  • On a categorizer or on a product

Executive ROI Value

Each table layout is built once and used for every family that needs it, instead of being rebuilt for each one.

  • Built once
  • Used everywhere

Operational Reality (Capabilities)

The Table Designer has five areas. The design surface is where a table is built from rows, columns, cells and cell elements; cells can be split and merged, and rows and columns added where they are needed. The output area renders the table with current data. The feature list shows the features available in the selected data source, the property panel shows the settings of the part in focus, and the data source panel lists the queries that feed the table.

  • Five working areas
  • Rows, columns, cells and cell elements
  • Output rendered on request

Executive ROI Value

The people who design tables see the real table, filled with real data, while they build it.

  • Real data
  • No guesswork

Operational Reality (Capabilities)

Every table is fed by named queries. A primary query is set up by default and can be changed: it reads the items in the current view, where the table is used, or the items in the related view, such as the products of a category. Because a table’s queries are fed the context of where it is used, the same design on two categories lists each category’s own products. Queries can also use the languages chosen when a report is run.

  • Primary query set up by default
  • Current view or related view
  • Results follow where the table is used

Executive ROI Value

One design gives each category and product a table of its own, with no copies to keep in step.

  • No copies
  • Always in context

Operational Reality (Capabilities)

Table Designer lays data out in Sets: the distinct values of a feature. Each cell projects its values in a direction, down or across, and each column’s values are narrowed by the value to its left and above it. Cells have four cell types: Static, for captions and fixed text in a single cell; Value, which projects values with a row each; Dynamic, which projects features; and Crossed, which works like Value. A cell element can show a feature’s value, caption, alternative caption, name, unit, abbreviation or variant.

  • Values projected down or across
  • Static, Value, Dynamic and Crossed cells
  • Value, caption, unit and more for each element

Executive ROI Value

Tables grow and shrink with the range, without anyone adding or deleting rows by hand.

  • No retyping
  • Grows with the range

Operational Reality (Capabilities)

A dynamic cell expands into many features, and each one projects its values into the output. Only features that contain values are included. The features can come from a value on each product, a multi-value feature that names the features to show and, being sortable, sets their order; from an information group; from a fixed list; from all features with values in the data; or from the features whose values are the same across all of it. These can be combined, for example every feature except those that are the same everywhere, or a group without two of its features.

  • Only features with values are shown
  • Five ways to choose the features
  • Lists combined, features left out

Executive ROI Value

One table design suits families with different specifications, without empty columns.

  • One design
  • No empty columns

Operational Reality (Capabilities)

Rows and columns can collapse: never, when empty, or always, which keeps a helper column, such as a unique ID, out of the visible output. Cell output merge combines repeated values into one cell: none, within a group, or beyond a group; it is a visual merge, shown in internal reporting. A cell can sort its values by any available feature, ascending or descending. Image elements have their own fit, Exact, Fit, Crop or Smart, with a fixed width and height in millimetres.

  • Collapse never, when empty, or always
  • Merge within or beyond a group
  • Sort by any feature; size images

Executive ROI Value

Tables print without blank columns, repeated values or images out of proportion.

  • Tidy output
  • Fewer reprints

Operational Reality (Capabilities)

Styles are assigned to the parts of a table, and the table’s hierarchy passes them down: a style on the table reaches its columns, rows, cells and cell elements, while a style on a cell overrides, for that cell, what comes from above. Named styles sit in a stylesheet, and a style can be based on another. They set borders, margins and padding, background and text colours, font family, style, size and stretch, trimming and wrapping, width and height in millimetres, alignment, line breaks and visibility.

  • Table style passed down; cell style overrides
  • Named styles, based on other styles
  • Fonts, colours, borders, alignment

Executive ROI Value

Every table carries the same look, and a change of style is made once instead of table by table.

  • Consistent look
  • Change once

Operational Reality (Capabilities)

When a report includes a table, the design is rendered with current data. The output joins the data for Perfion’s internal reporting engine, where the PerfionTable control shows it in a report design, and it appears in the InBetween export as Table XML blocks of rows and columns, carrying the table’s name. In internal reporting, a set number of header rows repeats when a table runs onto a new page, and a keep-together option keeps designs with split cells correct across pages, at the cost of a larger output.

  • PerfionTable control in internal reports
  • Table XML blocks in the InBetween export
  • Header rows repeated on new pages

Executive ROI Value

Datasheets, catalogues and publishing tools take the same table, built from the same data.

  • One source
  • Ready to print
Core Concepts

5 Core Concepts of Tables in Perfion

The first is about reuse and the second about layout. The third keeps tables free of empty columns, the fourth gives them one look, and the last takes them into print and publishing.

  1. Concept 01 · One design, many places

    Design a Table Once, Use It Wherever It Fits

    The product data problem it solves

    Seventy pump families each have a specification table, typed into the catalogue file and copied into datasheets and tender documents. A new column for cable length means opening all seventy tables, and two of them are missed.

    The concept explained

    A Table feature holds a table design and the queries that feed it, and it is selectable by default. The same design is picked wherever it is needed: on each catalogue category, or on individual products. When the table is rendered, its queries are fed the context of where it is used, so each category gets its own models and each product its own values. A change to the design reaches every place it is used.

    Everyday analogy

    A printed form with blank rows. Every branch office uses the same form, and each one fills it with its own figures.

    In Perfion

    A table on a categorizer such as a catalogue can draw on the category and the products related to it, for a table covering many products. A table on a product gives finer control. The primary query reads the items in the current view or in the related view, and can be changed later.

    Related:
    BPAS method · toolDeploy EnterpriseDesign before configurationThe data model is designed and signed off before anything is configured: the Design phase of toolDeploy Enterprise.
    Design a table once, use it wherever it fitsLeft: one Table feature, SpecTable, selectable, holding a design, a primary query and a stylesheet. Right: the same table used in three places: on category SP4 borewell pumps it reads the category’s 4 models and renders 4 rows; on category OW openwell pumps it reads 9 models and renders 9 rows; on product SP4-0510 it reads that one model. Bottom: context decides the rows: the table’s queries are fed the context of where it is used, reading the items in the current view or the items related to them.One design, a table for every place it is usedTable featureSpecTable · selectableDesignPrimary queryStylesheetCategory · SP4 borewell pumpsReads its 4 models4 rowsCategory · OW openwell pumpsReads its 9 models9 rowsProduct · SP4-0510Reads one model1 rowContext decides the rowsThe table’s queries are fed the context of where it is used: the items inthe current view, or the items related to them, such as a category’s products.
    One Table feature, three places: each category and the product get results of their own.
  2. Concept 02 · Values projected, then narrowed

    Think in Sets, Not in Rows

    The product data problem it solves

    A catalogue table lists models by power rating. Two models share a 0.75 kW rating, and the person building the table expects one row per model. The table shows one rating with two models beside it, and nobody can explain why.

    The concept explained

    Table Designer lays data out in Sets: the distinct values of a feature across the data the table reads. Each cell projects its Set in a direction, down or across. Each column’s values are narrowed by the value to its left, and by the value above it, so only combinations that exist in the data appear. Where two items share a value, they appear as one entry that expands to hold what belongs with it. To give every item its own row, the table starts from a feature unique to each item, and that column can be kept out of the output.

    Everyday analogy

    A school register arranged by class. Each class appears once, and under it, only the pupils who belong to it.

    In Perfion

    Boyum’s documented example projects names down and ages beside them: a name held by two people of different ages expands to show both. Adding a grouping above, such as gender over nationality, projects the first Set and then the second within each of its values.

    Related:
    Think in Sets, not in rowsLeft: the data the table reads: four models with their power: SP4-0507 at 0.55 kW, SP4-0510 at 0.75 kW, SP4-0710 at 0.75 kW and SP4-1015 at 1.1 kW. Middle: the Set of Power kW, the distinct values 0.55, 0.75 and 1.1, projected down. Right: the result when Model is added to the right of Power: each model is narrowed by the rating to its left, so 0.55 shows SP4-0507, 0.75 expands to show SP4-0510 and SP4-0710, and 1.1 shows SP4-1015. Bottom: where two items share a value they are condensed into one entry; to give every item its own row, start from a value unique to each item and keep that column out of the output with collapse.Each column narrowed by the one to its leftModelPower kWSP4-05070.55SP4-05100.75SP4-07100.75SP4-10151.1The data the table readsSet of Power kW0.550.751.1Projected downPower kWModel0.55SP4-05070.75SP4-0510SP4-07101.1SP4-10150.75 expands: two models share itOne row for every itemWhere two items share a value, they are condensed into one entry. To giveevery item its own row, start from a value unique to each item, then keepthat column out of the visible output with collapse.
    The Set of Power kW projected down; each model narrowed by the rating to its left, so 0.75 kW expands to two models.
  3. Concept 03 · Features that hold values, nothing else

    Show the Features a Product Actually Has

    The product data problem it solves

    One table layout serves every pump family. Openwell pumps have no cable length or outlet size, so their catalogue pages print two columns of dashes, and a dealer asks whether the data is missing.

    The concept explained

    A dynamic cell expands into a list of features, and only features that hold values are included in the output. The list can come from a value on each product that names the features to show, from an information group, from a fixed list, from every feature with values in the data, or from the features whose values are the same across all of it. Lists can be combined: every feature except those that are the same everywhere gives a table of what differs between the items.

    Everyday analogy

    A tailor’s card that lists only the measurements actually taken, not every measurement a tailor could take.

    In Perfion

    Dynamic cells are green in the Table Designer, and a dynamic value can show a feature’s caption or its value. If every listed feature is empty, one empty column remains; the column’s collapse setting can remove it.

    Related:
    Show the features a product actually hasLeft: six features listed for the openwell pump family: Power kW, Head m, Flow lpm and Stages hold values; Cable m and Outlet mm have no values. Middle: a dynamic cell that expands into the features with values. Right: the rendered table with columns Model, kW, Head, Flow and Stages for three models; cable and outlet are left out. Bottom: the features can come from a value on each product, an information group, a fixed list, all features with values, or the features that are the same everywhere, and lists can be combined, such as all features except those that are the same everywhere.A dynamic cell keeps only features with valuesFeatures listedPower kWHead mFlow lpmStagesCable mno valuesOutlet mmno valuesDynamic cellExpands intofeatures with valuesModelkWHeadFlowStagesOW-03100.37121201OW-05150.55151501OW-10201.1202002Cable and outlet left outWhere the features can come fromA value on each productAn information groupA fixed listAll with valuesSame everywhereLists can be combined: all features except those that are the same everywhere.
    Six features listed; the dynamic cell shows the four that hold values and leaves out cable and outlet.
  4. Concept 04 · Set at the top, overridden where needed

    Style Tables Once, From the Top

    The product data problem it solves

    Every catalogue table is formatted by hand. After a brand refresh, header colours differ between chapters, some tables have borders and some do not, and the proof goes back three times.

    The concept explained

    Styles are assigned to the parts of a table. A style set on the table passes down to its columns, rows, cells and cell elements, and a style set on a cell overrides, for that cell, whatever comes from above. Named styles live in a stylesheet and can be based on other styles, so a family of styles shares one base. A change to a style reaches every table that uses it.

    Everyday analogy

    A school uniform with a house badge: the uniform is the same for everyone, and only the badge differs.

    In Perfion

    The Table Designer uses the default stylesheet. When a report runs, a stylesheet included in the report template overrides the default, so tables take the report’s look. Style commands cover borders, spacing, colours, fonts, wrapping, sizes in millimetres, alignment, line breaks and visibility.

    Related:
    Style tables once, from the topLeft: the table hierarchy. The style Borders is set on the table and passes down to columns, rows, cells and cell elements. The first row also takes the style Header, and one cell takes the style SpecValue, which overrides what comes from above for that cell. Right: a preview table with borders, a dark header row and one highlighted cell. Bottom: the Table Designer uses the default stylesheet; when a report runs, a stylesheet included in its template overrides the default.Set at the top, overridden only where neededTableBordersColumnsfrom the tableFirst rowHeaderOne cellSpecValueCell elementsfrom aboveModelPower kWHead mSP4-05070.5538SP4-05100.7552SP4-07100.7540Borders from the table, Header on the firstrow, SpecValue on one cell onlyDesigner default, report overrideThe Table Designer uses the default stylesheet. When a report runs, astylesheet included in its template overrides the default.
    Borders set on the table reach every part; Header on the first row; one cell overridden with SpecValue.
  5. Concept 05 · Rendered once, used in print and publishing

    Render the Same Table for Every Output

    The product data problem it solves

    The catalogue, the datasheet and the tender document each have their own copy of a specification table. The catalogue is corrected after a rating change; the tender document is not, and a bid goes out with the old rating.

    The concept explained

    When a report includes a table, the design is rendered with current data. The rendered table joins the data for Perfion’s internal reporting engine, where the PerfionTable control shows it, and it appears in the InBetween export as Table XML blocks of rows and columns. Each output takes the table from the same design and the same product data, so a value changed in Perfion is in every table the next time it is generated.

    Everyday analogy

    One typeset page sent to every printing press, instead of each press setting the type again.

    In Perfion

    The report’s query must include the table feature for the table data to be there. In internal reporting, header rows can repeat on each new page, and a keep-together option keeps designs with split cells correct across pages, with a larger output. Cell output merge is visual: it applies to internal reporting, not to the InBetween output.

    Related:
    From BPAS · prodRecord newsletterprodRecordKeeping the record straight.One product data practice every month, written in plain English for product data teams.
    Render the same table for every outputLeft: the table design and the current data from its queries. Middle: the table is rendered when a report includes it. Right, top: internal reporting, where the PerfionTable control shows the table, header rows repeat on new pages and merged cells are shown. Right, bottom: the InBetween export, which delivers Table XML blocks of rows and columns with the table’s name. Bottom: cell output merge is visual only; it is shown in internal reporting and does not affect the InBetween output.Rendered once, into reports and exportsTable designRows, columns, stylesCurrent dataFrom its queriesRenderedWhen a reportincludes the tableInternal reportingPerfionTable controlHeader rows repeat onnew pages; merges shownInBetween exportTable XML blocksRows and columns, withthe table’s nameCell output merge is visual onlyIt is shown in internal reporting; the InBetween output is not affected.
    One rendered table: shown by the PerfionTable control in internal reports, and delivered as Table XML in the InBetween export.
Best Practices

10 Best Practices for Tables in Perfion

Each practice says what well-run tables look like and what it costs to ignore it. Designing them for your range and documents is what BPAS consultants do.

  1. 01Design one table for each kind of document, not one for each product

    Reuse · Designs

    The rule

    Each table design serves a whole family or document type and is reused wherever that layout is needed.

    Risk if ignored

    Hundreds of near-identical tables, each fixed separately when the layout changes.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 01Capability: Table features

  2. 02Place each table where its data lives

    Context · Placement

    The rule

    Tables that summarise many products sit on the category; tables about a single product sit on the product.

    Risk if ignored

    Category tables repeated for every product, or product tables that cannot show their family.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 01FAQ 04

  3. 03Check that every table reads exactly the items it should

    Data · Queries

    The rule

    Each table’s query is checked to read the items it needs, no more and no less, before the table is used in a document.

    Risk if ignored

    Tables quietly include items that should not be there, or miss the new ones.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Capability: Context-aware data sourcesVocabulary: Primary query

  4. 04Give every item its own row where rows must be counted

    Layout · Sets

    The rule

    Where each item needs a row of its own, the table starts from a value unique to each item, kept out of the visible output.

    Risk if ignored

    Two models with the same rating appear as one entry, and a model seems to be missing from the catalogue.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 02Vocabulary: Sets

  5. 05Let dynamic cells leave out empty features

    Content · Dynamic features

    The rule

    Families with different specifications use dynamic cells, so each table shows only the features that hold values.

    Risk if ignored

    Catalogue tables full of empty columns and dashes.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 03Capability: Dynamic features

  6. 06Give the lists behind dynamic tables an owner and an order

    Governance · Feature lists

    The rule

    Information groups and feature lists that feed dynamic cells have a named owner and a deliberate order.

    Risk if ignored

    A feature added to a group for another purpose turns up in every catalogue table overnight.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Capability: Dynamic featuresVocabulary: Dynamic cell

  7. 07Remove empty rows and columns from the output

    Layout · Collapse

    The rule

    Rows and columns that can be empty disappear from the output when they are.

    Risk if ignored

    Blank rows and columns waste catalogue pages and look like missing data.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Capability: Collapse, merge and orderVocabulary: Collapse

  8. 08Style tables from one stylesheet, and override only where needed

    Look · Stylesheets

    The rule

    Tables take their look from named styles set at table level; styles on single cells are kept for deliberate highlights.

    Risk if ignored

    Each table formatted by hand, and every brand refresh means reworking them all.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 04Capability: Table styling

  9. 09Check tables in the report they will print in

    Look · Reports

    The rule

    Table designs are signed off in the report that uses them, because a stylesheet in the report template overrides the designer’s default.

    Risk if ignored

    A table that looked right in the designer prints with other fonts and borders.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 04Vocabulary: Stylesheet

  10. 10Check long tables across page breaks

    Output · Reports

    The rule

    Long tables repeat their header rows on each new page, and designs with split cells are checked where a page break falls.

    Risk if ignored

    Second pages of specification tables without headings, or split cells drawn wrongly across pages.

    Get it right with BPAS

    Not sure this is in place for your tables? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 05Capability: Tables in reports and exports

Self-Audit · 10 Best Practices

Table design self-audit: how many are in place today?

Tick each of the ten practices above that your business already follows. Your score updates as you go.

Practices in place
0 of 10

Tick the practices that are in place.

Book a table design review

Nothing you tick is stored or sent.

Illustrative scenario · not a client case study A Business Like Yours

Illustrative scenario: an Indian pump maker, with seventy tables typed by hand

A maker of submersible, monoblock and openwell pumps sells about 1,400 models in 70 families through dealers, government and institutional tenders and a printed product catalogue. Orders, stock and invoicing are in the ERP. Every family has a specification table in the catalogue, in its datasheets and in tender documents.

The Operational Challenge

Every specification table is typed into the catalogue file or a spreadsheet, one for each family, and copied into datasheets and tender documents. When a rating changes, someone has to find every table that shows it. A catalogue revision takes about six weeks, most of it spent checking tables.

One layout serves all families, so openwell tables print empty columns meant for borewell pumps, and a model added after the last revision is missing from the dealer table.

  • Seventy tables typed by hand
  • Ratings retyped in three documents
  • Empty columns in many families
  • Six weeks for each catalogue revision

The Financial Transformation

In Perfion, one table design serves each kind of document, used on the catalogue categories. Its primary query reads the models in each category, so every family gets its own rows from the product data, and a dynamic cell shows only the specifications that family has. Columns with no values collapse from the output.

Tables take their look from one stylesheet, and the same tables reach the datasheet and catalogue reports and the InBetween export used for the printed catalogue. A rating changed in Perfion is in every table the next time it is generated.

  • One design for each kind of document
  • Rows built from product data
  • Only the specifications each family has
  • Catalogue checks in days, not weeks
Illustrative figures for a typical Indian pump maker of this size. They add up, but they are not a client case study.
Cost line Before (per month) After (per month) Difference (per year)
Building and updating specification tables₹ 1,20,000₹ 20,000₹ 12,00,000
Correcting table errors and reprints₹ 45,000₹ 8,000₹ 4,44,000
Making comparison tables for dealers and tenders₹ 30,000₹ 6,000₹ 2,88,000
Total₹ 1,95,000₹ 34,000₹ 19,32,000
Illustrative saving a year₹ 19,32,000Same figures as the table, not a client result

See how your own tables would be built from the product data in Perfion.

Book a table design review
From BPAS

prodRecord Live

Enterprise product data insights from BPAS

Keeping the record straight, live every month

prodRecord Live is a monthly webinar series on product information management, held on the second Wednesday of every month from January 2027. Each session takes one product data topic and works through it in plain English with time for your questions.

  1. Jan
  2. Feb
  3. Mar
  4. Apr
  5. May
  6. Jun
  7. Jul
  8. Aug
  9. Sep
  10. Oct
  11. Nov
  12. Dec
Explore prodRecord Live
12
Live sessions in 2027 Second Wednesday, monthly
Who Benefits

Who benefits from tables built from product data: one design, three answers

  • Promoter & CXOs

    Can our catalogue keep pace with new models?

    Tables are filled from the product data each time a report is generated, so a new model reaches every table without a separate revision.

  • Product Data Manager

    Will the tables show exactly what we hold?

    Each table reads the items where it is used, and dynamic cells show only the features that hold values.

  • Catalogue & Marketing Manager

    Will every table look the same, page after page?

    Tables take one look from a stylesheet, and header rows repeat on each new page in reports.

Vocabulary

Table Designer Vocabulary and Definitions

From Table features and Sets to cell types, dynamic cells and stylesheets. Each term shows what it means, why it matters, and a household comparison.

  1. Table feature

    Tables · basics

    Selectable by default

    Operational definition

    A feature that holds a table design and the set of queries that feed it.

    Why it matters in Perfion

    One design is reused across the system, and each use gets its own results.

    Everyday analogy

    A printed form that every branch office fills with its own figures.

    See it in action:Table features under Capabilities →

  2. Table design

    Tables · layout

    Rows, columns, cells

    Operational definition

    The layout of a table: its rows, columns and cells, and the cell elements that show feature values, captions or fixed text.

    Why it matters in Perfion

    Applied to the data from the queries, it produces the formatted table.

    Everyday analogy

    The blank grid of a printed register, before anything is written in.

    See it in action:The Table Designer under Capabilities →

  3. Set

    Layout · logic

    Distinct values

    Operational definition

    The distinct values of a feature across the data a table reads. Table Designer lays tables out by projecting Sets.

    Why it matters in Perfion

    Only combinations that exist in the data appear in the table.

    Everyday analogy

    The list of classes in a school, each named once.

    See it in action:Concept 02 under Core Concepts →

  4. Direction

    Layout · logic

    Down or across

    Operational definition

    The way a Value or Dynamic cell projects its values or features into the output.

    Why it matters in Perfion

    The same data can run down a column or across a row.

    Everyday analogy

    Writing a list down the page, or across it.

    See it in action:Sets, cell types and directions under Capabilities →

  5. Cell type

    Layout · cells

    Static, Value, Dynamic, Crossed

    Operational definition

    Static holds captions or fixed text in one cell; Value projects values with a row each; Dynamic projects features; Crossed works like Value.

    Why it matters in Perfion

    The type decides whether a cell holds one entry or spreads many.

    Everyday analogy

    A form with printed headings and boxes to fill in.

    See it in action:Sets, cell types and directions under Capabilities →

  6. Dynamic cell

    Content · features

    Only features with values

    Operational definition

    A cell that expands into a list of features, from a value, an information group, a fixed list or the data itself, and shows only those that hold values.

    Why it matters in Perfion

    One design suits families with different specifications.

    Everyday analogy

    A tailor’s card listing only the measurements taken.

    See it in action:Concept 03 under Core Concepts →

  7. Primary query

    Data · queries

    Set up by default

    Operational definition

    The query that feeds a table by default: the items in the current view, where the table is used, or the items in the related view.

    Why it matters in Perfion

    It decides which items the table reads, so it is checked before the table is used.

    Everyday analogy

    The guest list a caterer cooks for.

    See it in action:Context-aware data sources under Capabilities →

  8. Collapse

    Layout · output

    Never, when empty, always

    Operational definition

    A row and column setting that removes it from the visual output when it is empty, or always.

    Why it matters in Perfion

    Empty columns stay off the page, and helper columns stay hidden.

    Everyday analogy

    Folding away the empty chairs before the guests arrive.

    See it in action:Collapse, merge and order under Capabilities →

  9. Stylesheet

    Look · styles

    Named styles

    Operational definition

    A collection of named styles, each a set of styling commands, which can be based on other styles.

    Why it matters in Perfion

    Tables share one look, and a style is changed once for all of them.

    Everyday analogy

    A school uniform, with a badge for each house.

    See it in action:Concept 04 under Core Concepts →

  10. PerfionTable control

    Output · reports

    Internal reporting

    Operational definition

    The report element that shows a rendered table in Perfion’s internal reporting, linked to the table data.

    Why it matters in Perfion

    Datasheets and catalogues show tables built from current product data.

    Everyday analogy

    The frame on a printed page that the typeset table drops into.

    See it in action:Concept 05 under Core Concepts →

FAQ

Table Designer: questions product and catalogue teams ask

Short answers, each with a link to the part of this guide that explains it.

  1. A feature that holds a table design and the queries that feed it. When the table is rendered, the queries produce data and the design lays it out as a formatted table. Tables are usually selectable, so one design is reused across the system, and each use gets results for the place it is used.

    More on Table features

  2. No. A Swap Relation Table holds rows of data on a product, such as ingredients with a weight and a percentage, and is shown in the Item Editor. A Table feature holds no product values of its own: it lays out data already in Perfion as a formatted table for reports and exports.

    More on Guide 05: Swap Relation Table

  3. Not when they are designed to avoid it. Dynamic cells include only features that hold values, and rows and columns can be set to disappear from the output when they are empty, or always.

    More on Concept 03

  4. On a categorizer such as a catalogue, to cover many products at once, or on a product, for a finer-grained table. Its primary query reads the items where it is used, or the items related to them, and the choice can be changed later.

    More on Concept 01

  5. In Perfion’s internal reporting, through the PerfionTable control in report designs, and in the InBetween export, as Table XML blocks of rows and columns. Header rows can repeat on each new page in internal reporting. Cell output merge is visual and applies to internal reporting only.

    More on Tables in reports and exports

  6. No. The table module is available under licence. If Table features are missing in a Perfion system where the module has been bought, Perfion Support can help.

    More on Table features

  7. Yes. Tables are built from data held in Perfion itself, so this guide applies whichever ERP your other data comes from. What changes from one ERP to another is the integration that brings ERP data into Perfion.

    More on ERP integration

Still have a question?

Ask about your own products, categories and channels. A BPAS consultant will answer in plain English.

Ask BPAS
Works Together With

See your product tables built from one design

See how your specification and comparison tables would be designed once in Perfion and filled from your product data for reports and publishing. Choose the path that fits the ERP you run.

Running an enterprise ERP?Book a product data assessment On SAP Business One or Business Central?Explore Boyum solutions, B1UP and toolDeploy
World first · 2025The world's first Boyum Partner Center of Excellence.Hosted in the cloud and available for evaluation and proof-of-concept work across the Boyum Solutions portfolio.See it to believe it — get convinced by working on it.Explore the PACE sandbox