The Pyramid business system runs your orders and your website

You have had orders, stock, purchasing and accounts receivable in Pyramid for years. Now the product website or the customer portal needs to show the same items, prices and stock levels. Orders need to go back into Pyramid without anyone having to enter them again.

With the Pyramid business system, integration problems often start when nobody has decided which data is allowed to leave the system. The map of where each piece of data lives is the most important decision. It states who owns each piece of data, what the channels may show and which changes may be written back.

The Pyramid business system is your transaction core

A customer places an order from their agreed price list. The item is held in several warehouse locations and the customer has special delivery terms. The web interface needs to present the purchase clearly, while the business system needs to check that the order can be processed.

Pyramid Business Studio is a Swedish, modular business system for trade and manufacturing. For integration work, the combination of modules you have activated matters more than the full module range.

Transaction core here means that Pyramid is responsible for the business rules that govern items, prices, warehouse locations and orders. The connection should use the available routines for validation and traceability. The website publishes a defined selection and accepts orders within those limits.

Decide which system may change a piece of data before you decide how that data is transferred. Say the marketing department wants to change a product's display name. That change may belong in PIM, while the item number needs to stay stable in Pyramid. A new display name should be publishable without changing the order's item identity.

The system's long life also needs thought. For your project, you need to know the actual installation's version, modules and older customisations.

An old customisation may, for example, determine how delivery terms are set. If the web project overlooks that rule, a technically correct order can still be wrong for the customer. That is why finance, sales and the system owner need to approve the same map of the flows.

Your data has a home in every flow

Item identity and core attributes live in Pyramid. PIM can collect and enrich product information, which is then published to the product website, customer portal and reseller channels. Decide which fields PIM may change and which it may only read. Otherwise a sync can overwrite editorial changes.

Structured product information gives you one place to manage and enrich content before it is distributed to the channels. Keep the item number in Pyramid, while descriptions, images and channel copy are managed in PIM. Then the presentation can change without affecting the order's item identity.

Prices, agreements and discounts come from Pyramid. The portal shows the price for the logged-in customer, with the terms that apply. A separate discount calculation on the website creates rules that also have to be kept up to date.

Stock and warehouse locations are published as a copy, with a delay you need to allow for. Pyramid handles reservations and stock movements when the order is processed. So separate a displayed stock level from a confirmed delivery promise, especially when several channels use the same stock.

Orders and customer data are written back through a documented import routine. Limit the integration with the business system to defined fields and events. Also decide how the system handles a delivery address that changes at checkout.

Items, prices and stock are never written back from the channels, because Pyramid owns them. Orders and customers are the only flows that go back, and then through a documented import routine.

Sync changes using a marker or timestamp, and make the transfer idempotent. Then a repeated transfer gives the same result. You also need a status log of successful and failed records. Check item number, unit, VAT code, warehouse location and language before publishing.

The database decides how the connection is built

The inventory comes before the drawing. Find out the database engine, Pyramid version, activated modules and available access components. Also check who may configure the connection and who is responsible for operations.

Swedish installations may use Actian PSQL, formerly Pervasive SQL and Btrieve, or Microsoft SQL Server. PSQL is normally reached via Pervasive ODBC. SQL Server can be read with standard SQL tools. Pyramid Link Access can provide ODBC or OLE DB access for external web, analytics and portal solutions.

With SQL Server, you need to size backups, read permissions, indexing and load testing separately from the web platform. A heavy export can affect the business's day-to-day work even when the web server is running normally. So test while representative tasks are running in the business system.

With PSQL, you need to explicitly test the ODBC driver, DSN, character encoding and server access. The wrong setting can cause selective read errors. So try real item texts and customer data with Swedish characters, empty fields and long values. With Pyramid Link Access, the same principle of least privilege applies towards web, analytics and portal.

Give the connection the minimum permissions it needs. A process that only reads items should have rights for exactly that task. Separate identities also make it easier to see which process caused an error.

Measure batch time, number of changed records, error rate and delay to the published channel. The same decision about where data lives can require different tests depending on the database engine.

Attributes are published from a separate read model

A read model needs a clear update rule that states when it changes and what happens if a transfer fails. That decides how quickly new attributes appear and how you handle temporarily outdated values.

Pyramid's e-line can transfer attribute data to a SQL database on the web server via ODBC and routine 791, E-line Communication. The separate database gives the website a model for fast reads, without every page view having to query Pyramid's transaction database.

Your product website or PIM solution can use the publishing model. With PIM, you collect product information in a structured way, enrich it and distribute it to websites, customer portals and reseller channels. Read more about how PIM data is structured and used.

Limit which attributes are published and how often the model is updated. Also set a limit on how old information may be. If the transfer stops, the website needs to either show the last published values or mark the data as not current.

Give the read process a separate database user and appoint someone responsible for backups. Document how the model is rebuilt after a restore and how it resumes syncing from the last known state.

Technically valid values can still be misleading in trade. A sales unit, for example, can be misread. Have the business approve representative products with languages, packaging and attributes before publishing is widened.

In the specification, state the source, target, update interval, error queue and owner of rejected records. Separate missing values from fields that are deliberately empty. Otherwise the next transfer can delete a manual addition.

Swedish companies extend Pyramid in stages

Pyramid is often extended step by step as the business changes. Users, e-commerce, transport administration and electronic invoicing are added over the years, so an integration needs to reflect both the core flows and later additions.

When you extend a portal, a new module can affect which order statuses should be shown. A transport integration can add delivery references that were missing at the first launch. So document what each status means and state which system owns it.

One example of a solution in a Pyramid landscape is the new solution for Skyltar & Märken, part of Addtech. It is built on Glanser's Function Library and Litium, and integrated with Pyramid.

A long system life makes the integration scope harder to estimate than the interface suggests. An order button may need to account for credit blocks, back orders and customer exceptions. Those dependencies affect the budget.

Keep decisions about fields, statuses and exceptions together with the tests. Then you can see which parts are affected when the next module is added, and give both parties a shared basis for approving the change.

Invoices and personal data follow the order

A portal that only shows order status leaves responsibility for invoices undefined. Someone needs to own the link between order, invoice, credit note and attachments. The references have to work even when the documents are stored in different systems.

The Swedish Tax Agency's requirements for mandatory invoice details include a unique sequential number, the buyer's name and address, and the quantity and type of goods. They also include the taxable amount, unit price, VAT rate and VAT amount, for both electronic and paper invoices. According to the same guidance, electronically stored invoice details must remain readable and unchanged throughout the storage period.

An amount in the portal needs to be traceable to the full invoice record. Keep stable document references and decide where the original record is held. Test that an authorised user can find the right invoice from an order. Also check how a credit note is linked to the record and how attachments come along when data is read back.

The Swedish Tax Agency defines an electronic invoice as one issued and received in electronic format, with the recipient's consent as the main rule. Contracting authorities and entities must accept electronic invoices, with the European standard applying when no other standard has been agreed. The recipient and the agreement therefore need to decide the invoice channel. Orders and invoices need a stable link and a responsible storage location, credit notes and attachments need to refer to the right record, and for customer and contact data you need to decide purpose, access rights and deletion rules.

Personal data needs its own boundary. The Swedish Authority for Privacy Protection's principle of storage limitation means data is kept only as long as the purpose requires and then deleted or anonymised. Deletion also has to take into account records that must be kept under other applicable requirements.

A customer portal should therefore show a decided selection of customer, contact and order data. State what happens when a contact person leaves or the customer relationship ends. Copying every field from Pyramid means you also have to justify and maintain the whole copy.

This approach requires data cleanup before automation

You need to appoint people who own items, prices, warehouse locations and customers. They must be able to decide which duplicates are removed and which values apply. The supplier can build the checks, but the business has to decide what the data means.

Set aside time to test reading, order import, error records and reading back invoices. Use normal orders together with real exceptions. A test order without a discount, back order or alternative delivery address gives only limited approval.

Hold off on automation if publishing would spread wrong prices or stock levels. Then the data cleanup needs to be finished first. A connection can detect incorrect values, but someone on your side has to be able to fix them. An undocumented special rule needs to become an agreed way of working before the developer can build it.

A standard connector with a fixed scope suits you when product, customer, stock and order flows can be described clearly. It suits you less when every order has its own exceptions that nobody can put into words. In that case, decide whether the rule fits in the existing configuration or needs an isolated customer-unique part.

Also check whether the real need is in the business system itself. If Pyramid lacks the conditions for your agreed processes, that work needs an assessment of its own. A web connection does not fix a broken process in the business system.

A pure content website without prices, stock or orders, on the other hand, needs no order connection that writes back. Limit the scope to the data the visitor actually needs. That reduces the number of flows you have to test and maintain.

Three questions show whether the integration holds

Ask who takes responsibility for order validation when Pyramid is updated, and which actions are included without a new quote. The answer shows whether the integration has an owner after go-live or whether every upgrade becomes a new assignment.

Ask which fields the website and portal may publish, how long they are kept and how they are deleted when a customer leaves. The answer shows whether the supplier has thought about personal data or only about the flow.

Ask how orders, invoices and credit notes are linked between the systems and what happens when a transfer fails or runs twice. The answer shows whether the error handling is built or only promised. A walkthrough of integration with the business system describes how flows and responsibility can be divided.

Together, the answers show whether the map of where data lives holds up: Pyramid owns items, prices, stock and orders, while the website, PIM and portal publish or write back the fields you have decided on.

See how we work with integrations with the business system, and use your map of items, prices, stock and orders as a basis when you assess the next step.