Skip to content

The first month. Part 1: getting the database going

An empty database is not a system yet — it is a form waiting to be filled in. Before you can issue the first invoice, it has to be told who works in it, what you sell, where you keep the stock, which accounts you count money on, and what you already have on hand on the day you start.

This guide is about order. Every step builds on the previous one, and skipping ahead usually ends with a reference book that has to be redone. Part 1 takes the database to the point where work can begin; part 2 walks through the first full cycle — from purchase to money in the bank; part 3 closes the first month.

The details of every window are in the articles the links lead to. What follows is the sequence and the reasons behind it.

Why this order

Data in ERPJS refers to other data, and the references always point downwards:

people → company and currency → items and warehouses → business partners → accounts and tax → numbering → opening balances

An item card needs a unit, and a group, if given, must be in the item group list. A document needs a warehouse and a partner. A posting needs an account. So reference books are filled in from the simple to the complex, and balances last of all, when there is somewhere to put them.

Step 1. Who is going to work here

You start with people, because everything else depends on them: documents are signed by users, and permissions decide what a person sees.

  1. Create roles — by job, not by person: cashier, storekeeper, accountant. Five cashiers work the same way, so that is one role.
  2. Create the users and give them roles.
  3. Only then the employee cards. The employee code can be anything — it does not have to match a login, and a person who does not need to sign in needs no user. Code, name and date of birth are required: on save the system creates a «birthday» action in the calendar, and its author and executor is the user who saved the card.

Step 2. The company and the currency

Company information is a single card per company: name, address, bank details, director. It is what goes into every invoice and printed form, and it is what the customer sees.

The base currency is the currency of the books. Every posting, balance and report is counted in it; amounts in other currencies are converted at the rate of the transaction date. The setting will let you change it later, but it does not recalculate the postings already made: the earlier books stay in the old units, and reports mix numbers that cannot be compared. So this is decided once, before the first document.

This is also the moment to think about objects — analytical tags on postings: department, project, line of business, machine. They let you see income and costs in the dimension you need without breeding accounts. Objects can be introduced later, but documents already posted without them stay without the dimension — and those are exactly the first months of work.

Step 3. What you sell and where you keep it

The order inside this step is strict, because each reference book refers to the previous one:

  1. Units — pieces, hours, metres. They exist so the whole database says "pcs" one way instead of three.
  2. Item groups — power tools, consumables, protective equipment. A card belongs to at most one group (the field is optional), and groups are what reports, discounts and price lists are built on. A group is also one of the places a document takes its accounts from.
  3. Items and services — the catalogue of what you sell and what you do.
  4. Warehouses — the places stock sits in. A balance in the system is always "so much at such-and-such warehouse"; without a warehouse there is no balance at all.

Typing these in one by one only makes sense for dozens of positions. For hundreds of rows there is the XLSX import — a universal load into any register; the same mechanism will later serve for bulk edits.

Step 4. Who you work with

Contacts is one card for both customers and vendors: the role is set by flags in the card, not by separate reference books.

Along with them:

Step 5. The rules of money

This is the step most often put off — and it should not be: without it the very first posted document lands on the wrong accounts.

  1. The chart of accounts — the list of accounts.
  2. Account Usage — the company-wide default accounts. A document looks for an account along the chain document row → item card → item group → this window, and here the chain ends. The inventory cost account is also looked up on the location card: after the group, before this window. Revenue and the expense account follow other chains — see Item Groups. If the account is set nowhere, posting will stop right here.
  3. VAT — the table of rates: code, percentage and the tax accounts. Every document row carries a rate code; the tax is calculated from it and posted to those accounts.
  4. Rounding and payment modes — small things that show up in every document and at the till.

Step 6. Document numbering

Number series answer the question "from which number to which". One series is one register: invoices from 1001, orders from 2001. Without a series the system numbers straight through from one — that works, but then a number tells you nothing about the document, and posted documents cannot be renumbered. So series are set up before the first document, not after the hundredth.

Step 7. Opening balances

The moment the old system ends and ERPJS begins. Three things are entered, each in its own way.

Account balances — opening balances: a date and rows of "account → debit or credit". Debit and credit totals must match, the "Difference" must be zero. Two things to know: the amounts take effect as soon as the document is saved, regardless of the OK flag, and in reports they are added to postings as separate records. They are what carries stock and debts into the books on the start date — which is why the start documents below are entered without postings.

Stock balances — as a goods receipt dated on the start date: quantity and cost price per position. Stocktaking will not do here — it records what a count found, but it does not change balances.

Partner debts — as unpaid invoices: documents issued but not yet settled are entered as ordinary invoices with their real dates, so that due dates and debt ageing are calculated correctly. Clear "Update warehouse" on each such invoice: the goods are already in stock through the start-date receipt, and a posted invoice would take them out a second time.

Postings off for the start. Receipts and invoices post on their own to the stock, receivables and payables accounts — the same accounts the opening balances already hold, so the books would show the amounts twice. While you enter the start receipts and the old invoices, clear "Goods Receipts", "Inv. to Customers" and "Vendor Invoices" in Records from Subsystems, and tick them again afterwards.

If there is a lot of data and it sits in an old system, export it to Excel and load the file through Xlsx Import — into any register, hundreds of rows at a time. The «Import Initial Data» maintenance is not for this: it loads the starter kit shipped with the server into the current company, not your tables.

Making sure the start is right

Three checks, a minute each:

  • the trial balance or the account balance — the opening figures match what you entered, and debit equals credit;
  • the item status — quantities per warehouse match the real ones;
  • open customer and vendor invoices — the debt totals agree with the reconciliation statements from the old system.

Discrepancies are easy to fix at this stage: there are no documents yet, so the balances themselves can be edited. Once the first documents are posted, the same mistake needs a reversal.

What comes next

Part 2: the first cycle — purchasing, receiving into stock, selling, money in the bank, and what the system does for you at each step.