Most descriptions of order and invoicing software describe what the software can do. This one describes what a particular business actually does with it, which is a different and more useful thing, because several of the features below are switched off there by choice.
The business is in Bulgaria and takes orders through its website. The site moved to Atlantis in September 2026, bringing its order history with it. Customers pay cash on delivery or by bank transfer, and parcels go out with Econt, to an Econt office, to a locker or to an address.
I built it, and for this article I checked every step twice: against the code of the plugins involved, and against the site’s own settings in production. Where the two differ, the article follows the site.
The flow at a glance
- 01CheckoutThe order is saved with its lines, prices, discounts and delivery choice.
- 02Payment recordCreated with the order. Cash on delivery and bank transfer start as pending.
- 03InvoiceBuilt from the order’s own lines at checkout, one per order.
- 04E-mailsAn order confirmation to the customer, a notification to the business.
- 05Econt labelCreated from the order screen, with the delivery details read from the order.
- 06TrackingChecked every 15 minutes; the customer hears when it ships and when it arrives.
Who does what
Four plugins take part, on top of the free Atlantis core:
- Commerce owns the catalogue, the cart, checkout and orders, and the order e-mails.
- Finance owns payment methods, payment records and invoices, with their PDFs.
- Logistics owns shipments, tracking and the delivery e-mails.
- The Econt connection plugs into Logistics as a shipping provider: it knows how to talk to Econt’s API.
None of them imports another. In Atlantis a plugin talks to the rest of the system only through the kernel: it calls another plugin’s public API, or it listens for events. That sounds like a technicality, and in practice it decides a lot. It is why the courier connection is a separate plugin that could be swapped for another courier, and why a failure in one plugin does not take the others down with it.
1. Checkout
The customer fills the cart and goes to checkout. They choose how the parcel should arrive, an Econt office, a locker or their address, and how they will pay. The order is saved with its lines, prices, discounts and delivery choice, gets its order number, and starts in the status pending.
The moment the order exists, Commerce hands it on. It asks Finance to record the payment and to create the invoice, and it announces that a checkout has happened, which is what the e-mails listen for.
One design decision in this step is worth stating plainly, because it is the kind of thing that only shows on a bad day. If creating the payment record or the invoice fails, the order is still placed and the failure is logged. The alternative, refusing the order because the invoicing had a bad moment, is the worst possible outcome for any business that takes orders: a customer who wanted to buy and could not. So the order wins, and the gap is caught later, on the order screen, where it can be repaired from the order itself. More on that below.
2. The payment record
Every order gets a payment record at checkout. Its status depends on how the money actually moves, and the site offers two methods:
- Cash on delivery starts as pending. The courier collects the money when the parcel is handed over, days later.
- Bank transfer starts as pending. The money arrives in the business’s bank account on its own schedule, and only the business can see that account.
The software supports card payments too, and it treats them strictly: a card payment counts as paid only when the card provider confirms it, not when the customer presses the button. This site has card payments switched off.
When a bank transfer arrives, someone at the business marks the payment as received. That records the moment the order was paid, and it tells the rest of the system that the order is paid, which is the event other plugins can react to. It does not move the order to a new status by itself. Moving an order along is a separate, deliberate step, for reasons that come up in the section on statuses.
Cash on delivery could settle itself. Each payment method has a switch called "Collected on Delivery"; when it is on, the payment is marked paid automatically when the courier reports the parcel delivered, and the order with it. On this site that switch is off, so a person marks cash-on-delivery payments as received too.
3. The invoice
The invoice is created at checkout, from the order’s own lines, prices and discounts. It is never retyped, so it cannot disagree with what the customer bought: if the order says a discount applied, the invoice has the discount.
There is exactly one invoice per order. If anything asks for the order’s invoice a second time, a retry after a timeout, a repair from the order screen, the existing invoice is returned instead of a duplicate being made. The invoice starts as issued, or as paid if nothing is left to pay.
The business downloads the PDF from the admin, from the invoice list or from the invoice itself. Customers can be shown their invoices in their account, through a setting called "Show invoices in the customer account". It is off by default, and the setting’s own description explains why: turn it on only once invoices are issued for every order. This site has it off. Invoices are not attached to any e-mail.
4. The e-mails
Every e-mail in the flow is triggered by an event, not by someone remembering to send it:
- At checkout, the customer gets an order confirmation, and the business gets a new-order notification. The business’s copy goes to the notification address in the platform’s general settings, with its copy recipients, or to the administrators if no address is set.
- When the order moves to processing, and again when it is completed, the customer is told.
- When the parcel ships or goes out for delivery, the customer gets an "on its way" e-mail, and when it is delivered, a "delivered" one. These come from Logistics, driven by tracking.
- Cancelling an order through the admin’s order actions tells the customer, and a refund, once it has been processed, sends its own message.
A failed e-mail never blocks the step that triggered it. The order is not lost because a mail server was slow.
5. The Econt label
The label is created from the order screen, in an Econt panel. It reads everything it can from the order: the receiver’s name and phone, the delivery type, office, locker or address, the office or locker the customer chose, and the parcel’s weight, worked out from the products’ own weights. For a cash-on-delivery order it fills in the amount the courier should collect, which is the order total. Lockers are the exception: they take no cash-on-delivery amount.
The panel also has the options a sender actually varies from parcel to parcel, such as how the cash on delivery is handled and a packing list. The business prints PDF labels; the connection can also produce labels for thermal printers and images. Econt’s own SMS notifications can be switched on in the connection; this site has them off and relies on the e-mails.
Atlantis can create the label automatically as soon as an order is paid. The switch is called "Auto-create AWB on order payment", and this site has it off: the person packing the parcel creates the label. Automatic labels on payment could not help with cash-on-delivery orders in any case, because those are only paid after they are delivered.
Before it sends anything to Econt, the panel checks the order and says plainly what is missing: the order has to be saved, it needs a receiver name and a phone number, and an office or locker delivery needs its office or locker code. The fix is always to correct the order and create the label from it again. Typing the label into Econt’s website instead would work once and break the flow: the shipment would no longer match the order, and tracking would not find its way back.
6. Tracking
Once the label exists, the tracking number is written onto the shipment and passed on to the order, where both the business and the customer can see it.
Every 15 minutes a scheduled job asks Econt about the shipments that are still on their way: pending, ready, shipped or out for delivery. It checks the 200 most recently updated ones on each run, so a large backlog of old, stuck shipments cannot crowd out the parcels that matter today.
A status change is written onto the shipment and announced as an event. Two of them reach the customer by e-mail, as above: shipped or out for delivery, and delivered. The customer’s account shows each order, its status and a link to track the parcel.
How an order moves through its statuses
Orders move through five statuses, and not every move is allowed:
pending → processing, cancelled
processing → completed, cancelled
completed → refunded
cancelled (final)
refunded (final)A cancelled or refunded order cannot be reopened, and a completed order cannot be cancelled, only refunded. The rules live in one place in the code, and the admin’s order actions go through them, which is also where the status e-mails are sent from.
That is also why marking a payment as received does not complete the order. "Paid" and "done" are different facts. A bank transfer can arrive before the parcel is packed, and a cash-on-delivery order is delivered before it is paid. Keeping payment and status separate lets each one be true on its own schedule, and the person handling orders moves the order along when it really has moved.
The order screen: one place to look
Because the payment records, invoices and shipments all belong to the order, the order screen is where every question about a sale is answered. It lists the related payments, invoices and shipments, and a small panel compares them with the order and says when something no longer matches: an invoice for a different amount, a missing payment record, a shipment without tracking.
If an invoice or a payment record is missing, which is exactly the gap the checkout design above allows, a button on the order creates it from the order. Nobody rebuilds an invoice by hand from an e-mail, and nobody has to remember that the checkout had a bad moment three days ago: the order screen says so.
The settings that decide the flow
Each switch below changes the flow. They are all visible and changeable in the admin, and this is how this site has them set:
- Payment methods: cash on delivery and bank transfer on, card off.
- "Collected on Delivery" on the cash-on-delivery method: off. A person marks those payments received.
- "Auto-create AWB on order payment" in the Econt connection: off. Labels are created by hand.
- "Show invoices in the customer account": off. Invoices are downloaded by the business.
- Econt SMS notifications: off. Customers are told by e-mail.
- Label format: PDF.
None of these is a limitation of the software; each is a decision the business can revisit. Turning on "Collected on Delivery", for example, would take one manual step out of every cash-on-delivery order.
What is still done by hand
- Creating the label, from the order screen.
- Confirming a bank transfer, because only the business sees its bank account.
- Marking cash on delivery as received.
- Moving an order to processing and to completed.
- Packing, and checking what goes in the box.
None of these is typing the same fact twice. Each is a person looking at something the system cannot see, or a decision the business has chosen to keep.
The Atlantis core is free and open source under the MIT licence. The orders, the invoicing and the shipping in this flow are not part of it: Commerce, Finance, Logistics and the Econt connection are separate commercial plugins. On this site they are part of the project I built.
Typing every order more than once?
Describe how an order moves through your shop today.