Seven Days in the Form You Received It
Every till in this product is built on one assumption: goods go out and money comes in. Victoria's Second-Hand Dealers and Pawnbrokers Act 1989 is written for the opposite counter. Somebody walks in with something, you buy it, and three obligations start at once — a record of the transaction in a form the regulations prescribe, a seven-day period in which the goods must stay exactly as you received them, and for one class of goods a prohibition on paying in cash at all.
Seven days, and not merely unsold
Section 21(1) is the provision to read twice. For seven days after receiving second-hand goods, the dealer must keep the goods <em>in the form in which they were received</em> and without disposing of them in any way. That is two duties, not one. A dealer who buys a bicycle on Monday and strips it for parts on Wednesday has not sold anything and has still breached the section, because the goods are no longer in the form in which they arrived.
Section 21(2) then makes clear that seven days is a floor rather than a ceiling — it does not derogate from any longer obligation the dealer might have. And the section carries a third duty that is unusually concrete for a statute: a record of the place of storage of each item of second-hand goods in the dealer's possession or under their control. Not a stock figure. A location, per item.
A tender that is illegal for one kind of goods
Section 19A, inserted in 2017, does something no point-of-sale system we know of models. A second-hand dealer who buys or sells scrap metal must not pay for it, or receive payment for it, in cash. Payment must be by a cheque which is not transferable and not payable to cash, or by an electronic transfer of funds which does not involve e-currency, or by another prescribed form. The penalty attaches to each limb, and it is ten times the penalty on the record-keeping duties.
Read as a system requirement, that is a rule joining a tender type to a category of goods — and it runs in both directions, because it covers buying and selling. Our till has three tender types and no item dimension on a payment at all: a payment row references the sale, a method, an amount and a moment. Cash is one of the three and it is the default on a refund. A cheque, as we found from a different jurisdiction in <a href="/blog/the-cheque-in-the-drawer-is-a-dated-risk">The Cheque in the Drawer Is a Dated Risk</a>, is not a tender on the money-in side at all — which is awkward here, since a non-transferable cheque is one of the two named lawful methods.
Section 19B adds a different kind of rule: a dealer must not buy scrap metal consisting of a motor vehicle whose vehicle identifier has been removed, obliterated, defaced or altered, and must not sell, dispose of or possess such a vehicle unless a police officer has authorised it in writing. The buying prohibition has no exception. So one class of goods carries a check on the goods themselves before the transaction may happen, and an authorisation document that has to be recorded against the item afterwards.
A rule that says "not in cash, for these goods" needs a payment that knows what was bought. Ours knows which sale it settles and nothing about what was in it.
What the product has, in the wrong module
The interesting thing about this Act is that almost every capability it needs exists somewhere in the product — and mostly not where the till is.
Each requirement, and where the nearest capability lives
| What is required | Exists somewhere | At the till | Enforced |
|---|---|---|---|
| A transaction in which goods are received | Yes | No | No |
| The identity of the party the goods came from | Yes | Partly — configurable by you | No |
| A record in a prescribed form | Partly — configurable by you | No | No |
| The place of storage of each item | Yes | No | No |
| A holding period before disposal | No | No | No |
| Goods kept in the form received | No | No | No |
| A tender forbidden for a class of goods | No | No | No |
| A refusal that names its reason | Yes | No | No |
Built and maintained Configurable by you, not maintained by us Not built
Row one exists as a purchase order against a supplier — which works when the seller is a business you have onboarded and not when it is somebody who walked in. Row four is genuinely good and lives in inventory: a serialised unit carries a warehouse, a location, the date it was received and its last movement, which is close to exactly what section 21 asks for. Row eight is the one worth noticing: the product already refuses a movement and names the reason it refused, on the asset register — the mechanism exists and points at a different family of records.
That last row is the useful observation. When an asset cannot be moved, this product does not merely warn — it refuses, and the refusal tells the person what state the thing is in. The same shape is what section 21 wants: this item was received four days ago, it cannot be disposed of yet, and here is why. What is missing is not the pattern. It is that the pattern lives on assets, and the goods in question are inventory sitting behind a till.
The place-of-storage duty deserves credit too, because it is a duty most software would fail and this one does not. A serialised unit in this product carries its warehouse, its specific location, the date it arrived and the date it last moved — which is the discipline we argued for on its own commercial merits in <a href="/blog/tyres-batteries-serial-warranty-tracking">Serial and Warranty Tracking on Tyres and Batteries</a>. For a dealer, the same discipline is a statutory record.
The thing that has to be built first
Everything on the list above is downstream of one absence: there is no transaction in which the business buys goods over the counter from a person. The inbound path in this product is a purchase order raised against a vendor record, which assumes a party you have onboarded, with an account and, if you use the portal, a login. A member of the public selling a bicycle is not that party, and turning them into one to record a fifty-dollar purchase would be the wrong shape.
A counter purchase is a small transaction with an unusual set of fields: a party who is not a supplier, an identity check on that party, a description of goods that do not exist in your catalogue yet, a price, a tender that may be constrained by what the goods are, and a receipt date that starts a clock on the goods. It is a sibling of a sale rather than a variation of a purchase order, and that is how we would build it.
Four questions for a system that will buy over the counter
Show me buying something from a walk-in customer.
What you will probably hear
Raise a purchase order, or a negative sale.
How to read it
Both are workarounds and each loses something. A purchase order needs a supplier record for a stranger; a negative sale gives you no party, no identity and no receipt date on the goods. Ask whether an inbound counter transaction exists as its own thing.
Can a tender be blocked for certain goods?
What you will probably hear
You can turn tender types off.
How to read it
Globally, probably. Ask whether it can be off for one category and on for everything else, because that is the shape of this rule, and a payment row that knows only which sale it settles cannot answer a question about what was in the sale.
Can stock be held back from sale for a period?
What you will probably hear
Mark it as unavailable.
How to read it
Ask who has to remember to mark it, and who has to remember to unmark it. A holding period computed from a receipt date is a rule; a flag somebody sets is a habit. Ask also whether the till would refuse or merely warn.
Where is this specific item stored?
What you will probably hear
In the warehouse it was received into.
How to read it
Ask for the unit rather than the line. Serialised stock in this product carries a warehouse, a location and a received date per unit, which is a real answer; unserialised stock carries a quantity, which is not. For a statutory record of the storage of each item, the difference is the whole thing.
Our take
If you deal in second-hand goods in Victoria, the honest position is that our till is built for the other direction and a counter purchase is the missing transaction. Until it exists, the workable arrangement is serialised stock — which gives you the place of storage per unit that section 21(3) asks for, and a received date to count seven days from — with the party and the identity check recorded as custom fields and the holding period enforced by a rule your people follow rather than one the system applies. What we would build, in order, is the inbound counter transaction, then a disposal hold derived from the receipt date, then a tender restriction keyed to a category. The third one is small and slightly unusual, and it is the only place we have seen a statute make a payment method illegal for a kind of goods.
What AWRA OpsHub does today
- A serialised unit with its own place of storage, carrying a warehouse, a specific location, the date it was received and the date it last moved.
- A batch with a received date, a quality status and a recall status, held as values against the stock that arrived together.
- A refusal that names its reason, on the asset register, where a movement that the record's state forbids is declined with the state quoted back.
- Customer records with contacts and addresses, so the party on the other side of a counter transaction has somewhere to live.
- A full audit trail on the records involved, carrying the actor, the moment and the values that changed.
- A document vault with a checksum, a classification and an access log, where an authorisation document can be filed against a record.
- Custom fields on items, till sales and customers, so an identity reference or a receipt date can be recorded, reported and exported today.
More we can add to your workspace
- A counter transaction in which the business buys goods from a person, as a sibling of a sale rather than a purchase order against a supplier.
- An identity check recorded against that transaction, with what was presented and by whom it was seen.
- A holding period derived from a receipt date, so goods received four days ago are visibly not yet disposable.
- A refusal at the till when a holding period is running, using the same state-and-reason pattern the asset register already applies.
- A record that goods remain in the form received, so dismantling within a holding period is a recorded decision rather than an ordinary movement.
- A tender restriction keyed to a category of goods, applying in both directions, since this rule covers buying as well as selling.
- A non-transferable cheque and a non-e-currency transfer as named tender types, which are the two lawful methods this Act specifies.
Where we point you to a specialist
- We will not tell you whether you are a second-hand dealer or a pawnbroker within the meaning of this Act, or whether particular goods are scrap metal. Registration, the definitions and the exemptions decide who the Part reaches, and the consequences of the scrap-metal provisions are ten times the consequences of the general ones. That is a question for a Victorian adviser, and it decides which of two very different rule sets applies to your counter.
- We will not reproduce the prescribed record form. Both record-keeping duties require the form and the information the regulations require, and we read the Act rather than the regulations. If we build a counter purchase for you, the field list comes from the current regulations with the date we took it recorded, so a stale version is visible rather than assumed.
- We hold a position on where a holding period belongs, and it is a refusal at the point of disposal rather than a report afterwards. The product already does this for assets — a movement the record's state forbids is declined, with the state named in the message — and that is the pattern we would extend rather than a dashboard showing which items are still inside their seven days. A rule that only reports is a record of a breach, not a control against one.
The first item is the build and nothing else on the list is much use without it — a counter purchase with a party, a description, a price, a tender and a receipt date. The second and third follow immediately and are fields and arithmetic. The fourth is where it becomes a control rather than a register, and it reuses a pattern that already exists one module over. The sixth and seventh are the unusual pair, and they are small: a tender restriction by category, and two more named tender types on the way in. The fifth is a decision about what counts as changing the form of goods, and that one wants your input rather than ours.
What we can build for your market on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for your market, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a local payroll engine, a rate with a date on it, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Dated rates and the periods your obligations actually use
Effective-dated tax rates, so a document raised about a past period is computed against the rate that applied then rather than the rate that applies now, and a credit note that carries the tax split of the supply it reverses. Where a jurisdiction operates a sales-monitoring or fiscalisation scheme, data produced in the published format alongside the approved equipment rather than in place of it.
Banks, payments and pay periods that are not months
Bank statement feeds and local payment rails wired into the Payments Register, and a payroll period that matches your statutory pay cycle rather than the calendar month our schema assumes today. The second is a data-model change and we would quote it as one.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Income tax, superannuation or provident fund contributions computed on live employee records against your own pay cycle, with the returns produced in the layout your authority expects.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedTell us which direction your counter runs
A till that only sells is the right product for almost everybody and the wrong one for a dealer, and the difference is not a setting — it is a transaction that does not exist. If you want the tender side of this in more depth, <a href="/blog/forty-dollars-in-two-dollar-coins">money as pieces rather than amounts</a> and <a href="/blog/the-cheque-in-the-drawer-is-a-dated-risk">the cheque as a dated promise</a> are the two companion pieces.
Talk to us about your workspace