01 · The problem
One product becomes several different truths.
The ERP knows the price and product number. The market needs dimensions, packaging hierarchy, labels, images and quality-assured copy. Spreadsheets often fill the gap.
A spreadsheet works at first because it is quick to change. Over time, the same flexibility becomes a risk: no one knows which file is current, required fields are missed, units are mixed and a correction must be repeated across several channels.
The solution is not to force all product information into Fortnox. It is to decide which system owns each field and create a controlled workflow between the source, enrichment and publication.
Clear responsibilities
Fortnox is the source of business data. Pimble is the workspace for enrichment and control. GS1, Validoo and other channels receive approved information.
02 · Target state
A workflow that stops errors before publication.
Steg 01Sync
Product numbers, names, prices and other business fields are retrieved from Fortnox.
Steg 02Enrich
The product team adds dimensions, GTINs, packaging, labels, copy and images.
Steg 03Validate
Rules check required fields, formats, relationships and channel requirements.
Steg 04Granska
An accountable person reviews deviations and approves the version allowed to leave the workspace.
Steg 05Publish
Only approved values are sent to GS1, Validoo or other recipients.
Steg 06Follow up
Status, errors and changes can be traced to the product, rule and point in time.
Publication is a decision, not an automatic side effect
A sync from Fortnox should not automatically publish incomplete information. Import and publication must be two separate steps. Business data can then update continuously while channel data waits until all rules are met and an accountable person has reviewed the change.
↳
Continue reading
Unlock the rest of the guide.
Leave your email to unlock the complete guide immediately and receive the PDF in your inbox. If you choose, we can also follow up with relevant examples for Fortnox, product data, GS1 and Validoo.
Your interest is tagged asProduct data & PIMPimble · Fortnox · GS1 & Validoo
03 · Building blocks
Three layers with different responsibilities.
SourceFortnox
Owns product numbers, financial fields and the foundation already used in the organisation's business processes.
Control layerPimble
Brings together enrichment, validation, review and status between the ERP and external recipients.
pimble.se ↗
RecipientsGS1 & Validoo
Receive structured, quality-assured product information according to their respective requirements and processes.
04 · Data model
Assign an owner to every type of field.
When two systems may both change the same field, conflicts arise that synchronisation cannot resolve. Document field ownership before building the integration.
| Field type | Primary owner | Kontroll | Exempel |
|---|
| Business identity | Fortnox | Unique and stable over time | Product number, status, base name |
| Logistics | Pimble or designated master source | Unit, plausibility and packaging relationship | Weight, dimensions, case size |
| Global identity | Pimble with a business rule | Format, check digit and uniqueness | GTIN and GLN references |
| Marketing content | Pimble | Language, length, required claims | Description, ingredients, images |
| Channel status | Pimble | Derived from validation and publication | Incomplete, ready, published, error |
Distinguish empty, unknown and not applicable
An empty value may mean the information is missing, has not been reviewed or does not apply to the product type. Model the difference. Otherwise validation rules fill with exceptions and the user cannot tell whether an empty field is an error.
05 · Quality rules
Make quality concrete and visible.
- Completeness: all required fields for the selected product type and channel are present.
- Format: the value follows the correct data type, character set and standard.
- Plausibility: net weight is not greater than gross weight and dimensions use the correct unit.
- Relationship: consumer unit, inner pack and case relate mathematically.
- Consistency: brand, language and names are consistent across related products.
- Publishability: only reviewed values and approved images leave the workspace.
The error message is part of the product.
State which value is wrong, why it is needed and how the user fixes it. “Validation failed” merely creates another support ticket.
06 · Implementation
Move one product family at a time.
- Choose a bounded range. Choose a product family with known owners and a manageable number of products.
- Map today's files. Identify which fields exist where, who updates them and which recipients use them.
- Decide field ownership. Document source, editing rights, validation and publication target for each field.
- Import without publishing. Run synchronisation and rules until deviations are clear and manageable.
- Publish in a controlled way. Start with one channel and manual approval, then track errors and lead time.
- Close the old workflow. Once the new path is proven, old spreadsheets and parallel updates must be retired.
07 · Measurement
Measure whether information becomes ready faster.
- Time from a product created in Fortnox to a publishable product.
- Share of products that pass validation without rework.
- Number of errors by rule, product family and source.
- Share of fields with a clear owner and last-reviewed timestamp.
- Number of manual file transfers and parallel registers remaining.
- Time from a detected channel deviation to corrected publication.
08 · Checklist
Ready to leave the spreadsheet behind?
Every field has a documented primary owner.
Import and publication are separate events.
Products have a clear status for each recipient.
Required fields are governed by product type and channel.
Units and packaging relationships are validated.
Changes can be traced to a person and point in time.
Error messages describe both cause and solution.
The old parallel workflow has an end date.
By Hugo!