What an account decides
A customer account carries several settings, and they are not equal. Some change what Yessort does. Others are recorded and nothing reads them.
Knowing which is which matters, because a setting that looks like a control and is not will let you believe something is protected when it is not.
Settings that act
| Setting | What it does |
|---|---|
| Invoicing strategy override | Decides whether this account's orders get an invoice each or a daily summary. Overrides the channel's default |
| Payment terms | The first link in the chain deciding when payment is due |
| Accounting contact | The reference used when posting this account's documents |
| Currency | The currency of the account's orders |
Settings that only record
| Setting | What it does not do |
|---|---|
| Credit limit | Nothing checks it. No order is blocked, held or flagged for exceeding it |
| Fulfilment policy (strict or partial allowed) | Nothing reads it. It does not change how lines are picked or allocated |
| Account type "reseller" | Nothing behaves differently because of it |
These are real fields you can set, and they are shown on the account. They are a record of your commercial arrangement, useful to a person reading the account. They are not controls.
The credit limit in particular
This is the one worth being blunt about, because the name implies enforcement.
Setting a credit limit does not limit anything. An account with a £5,000 limit can place a £50,000 order and nothing will stop it, warn about it, or hold it for review.
If you rely on credit control, it has to happen outside Yessort — in your accounting system, or as a process someone follows. Recording the limit here is useful as a reference; treating it as a safeguard would be a mistake.
The fulfilment policy in particular
Strict and partial allowed describe an intention about whether part of a line may be sent when the whole cannot. Nothing acts on the setting: picking and allocation behave the same either way.
It is worth recording if it reflects an agreement with the customer, so whoever handles their order knows. It will not enforce that agreement.
Why document this
Because the alternative is worse. A page listing every field as though each were a control would read as a promise, and the first time someone discovered the credit limit did nothing, it would be at the point it mattered.
If either of these gains real behaviour later, this page is where it will change.
Related
Payment terms for the chain deciding when payment is due, and invoicing strategies for how the override fits with the channel's default.