Portal Catalogue

1Why a group, and not a login #

Most customers end up with more than one portal login — the owner and a couple of clerks. If the catalogue were attached to a login, those three people would see three different catalogues, and adding a fourth person would quietly show them nothing.

Publishing to the customer's group makes the customer the unit. Everyone at that customer sees the same list, and a new contact inherits it without anyone remembering to.

These are the same groups that already drive custom rate and discount, so a group is usually already the right shape: customers who buy on one set of terms are normally the customers who should see one catalogue.

2Step by step #

Decides which products each customer group sees in the portal catalogue.

1. Pick the customer group to configure.
2. Allocate the products (or ranges) it may see and save with F5 .
3. Portal users in that group see the change on their next catalogue load.

3How a customer gets into a group #

Two ways, and both count:

• On the account — the ledger account's own custom group.
• Group member — an entry in the customer group's member list.
• Both — recorded both ways, which is common and harmless.

The Who this reaches list says which route each customer came by. It matters when removing somebody: taking them out of the member list does not remove them if their account still carries the group.

Add / remove edits the membership list — search for a customer and tick them in. Only live customer ledgers are offered, so a bank or a tax ledger can never end up in a catalogue group. A customer already in another group is flagged, since moving them changes what they see.

A customer marked set on the account cannot be unticked here. That group lives on the ledger account and also drives custom rate and discount — changing a customer's pricing group as a side effect of editing a catalogue would be a surprise nobody could trace back to this screen. Change it in the account master instead.

4Publishing, and what an empty catalogue means #

• Tick On the portal against each item, then Save (F5) . Only what you changed is written.
• Tick all listed / Untick all listed apply to the rows on screen and become ordinary ticks — nothing is written until you Save, and Esc discards them.
• Select ALL … matching is different, and the button says how many it means. It applies to everything the filters match — which is usually more than the grid has loaded — and it writes at once . It asks first, because it is the one action here you cannot discard. Any unsaved ticks are dropped when it runs, since the list underneath them has changed.
• A group with nothing published is flagged in the list. Its customers can sign in and will find an empty portal, which they will report as a fault rather than as a setup step.
• Publishing reaches nobody until a customer in the group has a portal login. The panel says so when none does.
• Nothing here changes prices. Rates still come from the ERP's own price resolution, exactly as they will on the order.

5What the customer still will not see #

Publishing is necessary, not sufficient. A published item is still hidden from a customer when it is inactive , or when it is not visible in the branch they signed into ( BrVisibility and the branch allocation). The portal applies those first.

Stock is a separate question again: what the portal shows as available is physical stock less what is reserved and blocked, which is why an item can be published, visible, and still not orderable.

6Why is a list empty? #

• No customer groups — none defined in this company. Create one in the ERP's customer group screen.
• No products — the filters are too narrow, or every item is inactive. Switch on Include inactive items to check.

7Shortcut keys #

• F5 — save the ticks you have changed.
• Esc — discard unsaved changes.

8If something does not work #