Transaction Types

A Transaction Type is the definition behind an entry form — what the form asks for, and how it turns what you type into a balanced entry. (Indian users will recognise this as a voucher type.) Manage them at Accounting → Transaction Types.

Every transaction type does exactly one thing: create a double entry. Nothing more. The difference between them is only how much accounting you have to think about. A transaction type decides the debits and credits for you, so you can work in business language — who paid, how much, against which invoice — instead of deciding what to debit and what to credit.

Journal is the one exception, and it is deliberate. It is the raw two-sided entry where you choose both sides yourself, for experienced accountants who want to post exactly what they intend, including corrections and adjustments no purpose-built form covers. Everything else in Dealersip keeps the double entry behind the scenes.

Built-in types (the ones on the New Transaction menu): Deposit Cash, Journal, Payment, Receipt, Withdraw Cash.

• Journal — the expert, two-sided entry described above; you pick the accounts on both sides. Used for adjustments and set-offs.
• Receipt and Payment — guided money-in / money-out forms that hide the debits and credits. A receipt puts money into a bank or cash account and settles it against open sale invoices; a payment takes money out and settles open purchase bills.
• Deposit Cash and Withdraw Cash — guided cash-transfer forms between your cash and bank accounts.

Beyond these, Dealersip posts its own entries for sales, purchases and opening balances. Those aren't on the New Transaction menu and you never enter them by hand.

Finding a transaction type

The screen opens on a list of every type you have, with a count of Total Transaction Types above it. Along the green bar at the top are a Search transaction types… box and the Add New button that creates one.

Each row shows three things: the Transaction Type name, the System Type it is based on, and an Entry tag reading either System or Manual.

System Type names the built-in behaviour the type is built on — the engine underneath it, rather than something you act on. It is there so you can tell at a glance what a renamed type really does: a type called "Supplier Bill" that shows Payment as its System Type behaves like a payment, whatever it has been called.

On the left of each row is a pencil to open the type, and either a bin to delete it or a lock where deletion is not possible.

What ships, and how much of each you can change

Dealersip ships two kinds of transaction type, and the difference decides how much you may alter.

System types

Marked System in the list and showing a lock instead of a bin. They can never be deleted, and how far you can configure them varies:

• Journal and Opening Balance are not editable at all. They open read-only. These two are the foundation of the double-entry system, so nothing about them can be altered.
• Payment and Receipt are partly configurable. You may change the name and the allowed account groups on the debit and credit sides — so a Receipt can be limited to the bank, cash and card accounts you actually deposit into. Everything else is greyed out and stays as built: the fixed side, the customer/supplier settings, sales tax, the wording labels, the reference field, settling outstanding items and attachments. Those are what make a Receipt behave like a receipt.

Types shipped ready to change

Deposit Cash and Withdraw Cash are shipped with Dealersip but are not system types. They are marked Manual, and they are fully editable — every setting on the design form is open to you, exactly as if you had built them yourself. Treat them as worked examples you are free to reshape.

The types you create

Anything you add is fully editable and, while unused, deletable.

Designing your own transaction type

Custom transaction types exist so you can shape accounting entries however your dealership needs them.

Consult your accountant before configuring a transaction type. These settings decide what gets debited and credited on every entry made with the type. Configured wrongly, they can seriously corrupt your accounting.

Add New, the button at the top right of the Transaction Types screen, opens the setup form. Each setting is explained below, in the order it appears. Options that only matter in certain setups stay hidden or greyed out until they apply.

Transaction type name

What the type is called. This is the name users pick from the New Transaction menu, so name it after the job it does — "Supplier Bill", "Expense Voucher", "Owner Drawing". Names must be unique — reuse one and Dealersip refuses with "This transaction type already exists". A type you create appears on the New Transaction menu as soon as you save it.

Which side is a single fixed account?

The most important choice on the form. Some transactions always post to one account on one side and list everything else in a grid on the other side — a Bill, for example, always credits Accounts Payable while the expense rows are entered against it.

• No fixed side (users pick both sides) — a plain journal. Users choose accounts on both sides and must balance the entry themselves. (See "Entering a custom transaction (no fixed side).)
• Debit side is one fixed account — the debit is fixed; the grid rows are credits.
• Credit side is one fixed account — the credit is fixed; the grid rows are debits.

Choosing a fixed side reveals the next two settings.

How is that account chosen?

Appears once you choose a fixed side.

Decide how much freedom the user has over that account:

• Only the accounts I choose — you name the accounts. Pick one and it is pinned to every transaction of this type (the user just sees it, and cannot change it). Pick several and the user chooses between them.
• Any account in the groups I choose — you name the account groups instead, and the user may pick any account inside them.

Fixed accounts / Account groups to pick from

Appears once you choose a fixed side; which of the two you see follows your answer above.

The list that goes with the choice above — either the specific accounts, or the account groups. You do not need to set the allowed groups for this side separately; Dealersip works them out from what you pin here.

Add up all the grid rows and post the total to this account automatically

Appears once you choose a fixed side.

Tick this and the user never types the fixed-side amount — Dealersip totals the grid rows (including tax) and posts that total to the fixed account. Leave it unticked when the user should type the amount themselves, which is what a settle-outstanding transaction needs.

Debit side can use / Credit side can use

Which account groups users may pick from on each side. This is what keeps entry sensible — a supplier bill can be limited to expense groups, so nobody posts one to a bank account by accident. A side that is a single fixed account is not shown here, because it is already decided.

Ask for a customer or supplier on this transaction

Tick this when the entry should record who it involves — a supplier for a bill, a customer for a receipt. Leave it off for transactions that involve no outside party, such as a transfer between your own accounts. Ticking it reveals the four settings below.

Where is it entered?

Appears once "Ask for a customer or supplier" is ticked.

• One for the whole transaction — a single name at the top of the form. Use this when everything on the entry concerns the same party.
• One on each row — every grid row carries its own name. Use this when a single entry covers several parties at once.

Limit to party types

Appears once "Ask for a customer or supplier" is ticked. Optional.

Restrict the picker to certain party types, so a supplier bill only offers suppliers. Leave it empty to allow any party type.

What to call it on the form

Appears once "Ask for a customer or supplier" is ticked. Optional.

A label so the form reads naturally in context — Supplier, Customer, Received from. Left empty, the field is simply called Party.

Party must be filled in

Appears once "Ask for a customer or supplier" is ticked.

Makes the name mandatory — the transaction cannot be saved without it. Settling outstanding invoices needs this on, so if you turn that option on, Dealersip ticks this for you (see below).

Allow sales tax on this transaction

Tick this if entries of this type can carry tax. It adds the Sales Tax column to the grid and reveals the setting below. Leave it off for transactions that never involve tax, such as a cash transfer.

Amounts are usually entered as

Appears once "Allow sales tax on this transaction" is ticked.

How users normally type amounts on this form:

• Before tax (tax added on top) — the usual choice; tax is calculated and added.
• Tax included in the amount — the amount already contains the tax, which is worked back out of it.
• No tax by default — tax is available but off unless chosen on a row.

Columns in the entry grid

The columns of the entry grid: Account / Category, Description, Amount, Sales Tax, Name (Customer/Supplier), Class, Billable and Markup %. For each you can:

• Tick it on or off to show or hide the column.
• Rename it by typing over the label — the box shows the standard name until you do.
• Mark it Required, so a row cannot be left with that box empty.
• Drag it by the handle to change the column order.

Account / Category and Amount are always shown and always required — an entry cannot exist without an account and an amount — so their boxes are ticked and cannot be changed. (Today the entry grid renders Account / Category, Description, Amount, Sales Tax and Name; Class, Billable and Markup % can be switched on here but do not yet appear on the entry form.)

Number label

An optional name for the transaction's number field — for example "Bill no.". Left empty, it is simply "No.".

Amount label

An optional name for the amount field — for example "Amount paid". Left empty, it is "Amount".

Fixed account label

An optional name for the fixed-account field — for example "Pay from" or "Deposit to". Left empty, it is "Account".

Show a reference number field

Adds a free-text reference box to the form, for a cheque number, a supplier's invoice number, or any document reference you want recorded with the entry.

Let users settle outstanding invoices / bills

Turns the entry grid into a list of the party's open invoices or bills, so a payment can be applied against them.

It is greyed out until you choose a fixed account side, because there has to be one account for the money to come from or go to. Pick a fixed side and it becomes available. (If you later switch back to "No fixed side", it switches itself off again.)

Ticking it sets three other options for you, because settling only works with them. Dealersip turns on "Ask for a customer or supplier", sets it to "One for the whole transaction", ticks "Party must be filled in", and unticks "Add up all the grid rows" — then tells you it has done so. The reason is practical: outstanding amounts are looked up per party, so the form needs one required party to know whose invoices to load, and the user must type the amount rather than have it totalled from rows.

These stay locked together while the option is on. If you change one of them back — switch the party to per-row, untick "Party must be filled in", or tick "add up all the grid rows" — Dealersip restores the combination it needs. To change them freely, untick "Let users settle outstanding invoices / bills" first.

See Settling outstanding invoices and bills below for how the direction is decided.

Allow file attachments

Lets users attach files — a scanned bill, a receipt, a cheque image — to entries of this type. On by default.

Preview

Opens the entry form exactly as users will see it, before you commit. Use it to check the wording and columns make sense in practice. Previewing saves nothing — it is purely a look at the form, so you can try it as often as you like. When you are satisfied, press Save and Close, or Save and Add New to set up another.

Settling outstanding invoices and bills

Ticking "Let users settle outstanding invoices / bills" turns the entry grid into a list of the party's open items. It needs three things set: a single fixed account side, a customer/supplier that is required and entered once for the whole transaction, and the amount typed in (not added up from the grid).

The direction is decided by which side is fixed. If the debit side is the fixed account — that is, your bank or cash accounts, so money is coming in — the form loads outstanding sale invoices. If the payment accounts are on the credit side, money is going out, so it loads unsettled purchases.

What the finished entry form looks like

Whichever shape it takes, the form carries a date, an automatic number, an optional reference, a note and (if allowed) attachments — and Create Party / Create Account links so you never have to break off to set something up first.

The middle of the form is one of three shapes:

• Grid against a fixed account — the fixed account sits at the top with the amount; the rows below it carry your chosen columns. The totals show Subtotal, Tax and Total.
• Journal style (no fixed side) — rows on both sides, with Total Debit and Total Credit shown separately and an out-of-balance warning until they match.
• Settle outstanding — an Outstanding transactions table listing each open Invoice / Bill with its Date, Original, Balance and the Payment you are applying, with a select-all tick. Totals show Amount, Allocated and On account. Anything you don't allocate stays on account as an advance. If the party has nothing outstanding at all, Dealersip says so and asks which control account the unallocated amount should go to.

Receipts and Payments follow that last shape, with wording to match: a receipt asks Received from and Deposit to; a payment asks Paid to and Pay from.

Changing a type that is already in use

Dealersip lets you reconfigure a transaction type even after transactions have been posted with it. That is deliberate — you get real freedom to reshape a form as your dealership changes — but the freedom has a cost, and it is worth understanding before you use it.

Nothing already posted is rewritten. Existing transactions keep the accounts and amounts they were saved with, your ledgers stay correct, and your statements do not move. What changes is how those older transactions behave when someone next opens one on the new version of the form.

What you will see, depending on what you changed:

• You changed the allowed account groups. An older transaction may not open properly for editing: the account list on the side you changed comes up empty, because the account it was posted to is no longer among the ones the form offers.
• You hid a column in the entry grid. The data behind it is still there and still correct — hide the party column, for instance, and each line keeps its party, the amount still appears on that party's ledger, and nothing in your accounts changes. But the entry form no longer shows it, and filtering on it stops working.
• You hid a column you now need to change. This is the trap. Because the control is gone from the form, there is no way to alter what sits behind it. With the party column hidden you cannot clear a party from a transaction, however much you want to.
• You removed the grid. Settlements attached to an older transaction are dropped when that transaction is next edited and saved. Simply viewing it is harmless; saving it is what applies the loss.

The rule of thumb. Changing a type's configuration is, in effect, a statement that you do not intend to go back and edit the entries already made with it. That is usually fine — old entries stay right where they are.

But if you need the new behaviour and you still expect to work on the older transactions, do not reshape the existing type. Create a new transaction type instead and leave the old one in place for its own history. Nothing stops you having both, and it costs you nothing: there is no limit on how many transaction types you can have.

Deleting a transaction type

A rule that runs through the whole of Dealersip applies here too: nothing can be deleted once anything has been recorded against it. So a transaction type that has been used for even one transaction cannot be removed — deleting it would break the entries that depend on it.

On top of that, system types can never be deleted at all, used or not. They show a lock where the bin would be.

That leaves types you created, or the shipped Manual ones, while they are still unused. If you cannot delete a type you no longer want, rename it so nobody picks it from the New Transaction menu by mistake.