From Excel manifests to a CRM: how ASTRUM brought shipments, pieces and trips into one portal

What it looked like day to day

• The trip manifest was assembled in Excel. Each of the eight managers kept their own spreadsheet with their own customers. No overall picture of a trip existed until someone merged the files by hand.
• Orders were retyped into the spreadsheet manually. A customer sent in an order; the manager copied over the shipper, the consignee, addresses, piece count, service type and payment terms — dozens of fields for every consignment.
• Five documents were typed by hand in Word. The transport order, invoice, completion certificate, contract and CMR were produced from scratch for every consignment. Company details were requested and typed in again, even for repeat customers.
• Labels were printed one at a time. Piece labelling was done in a separate app, and every label was created individually. A batch of twenty pieces meant twenty identical operations.
• Shipment status was chased down a chain. The customer called or messaged the manager. The manager first worked out which trip the shipment was on, then checked the truck on the map, then called the customer back.
• The same data lived in several places. Shipment information sat with the managers and with the executives, the versions drifted apart, and reconciling them ate time.

No single step here looks like a problem on its own. What makes it a problem is volume: at a hundred trips a month and hundreds of shipments, manual operations stop scaling before the company has time to notice.

What triggered the change

There was no disaster that forced the change. The decision was made ahead of trouble: the company watched its competitors, saw the transport market going digital, and did not want to be left behind. It was a deliberate choice to grow, not a reaction to a loss.

ASTRUM started by looking for a partner on the inventory side. The company found iWeb through the official MoySklad partner directory — iWeb works with that platform and is listed there. The first consultation was about warehouse tracking.

That conversation made it clear the problem had not been fully framed yet, and iWeb proposed a proper process audit. The audit showed that a forwarder's bottleneck was not in the warehouse: time was being lost between the order, the paperwork and the trip. So a warehouse project became a CRM implementation on Bitrix24.

Three entities instead of one pipeline

The core of the whole design is three linked entities, each with its own fields, stages and assigned owner:

• Shipment — a customer's consignment: who ships, to whom, where, on what terms, for how much. Managed by the sales managers.
• Piece — what physically sits in the warehouse: a specific box, bag or pallet inside a shipment. Managed by the warehouse.
• Trip — a truck with a driver and a route that carries it all. Managed by logistics.

On paper the split looks obvious, but it is exactly what solves the original problem. A manager works their shipment and stays out of the truck. The warehouse supervisor receives pieces and never opens the commercial terms. The dispatcher builds a trip out of ready shipments. And all three look at the same database, so the data never drifts apart.

Shipment: the order, the money and the paperwork in one record

The shipment became the centre of all work. A customer's order turns into a shipment record, and from then on everything lives in that record: shipper and consignee, addresses, service type, piece count, amount, the goods list and the full document pack.

There is no separate deal pipeline in the process. Keeping a classic deal alongside the shipment was considered early on — but then a manager would run one consignment in two places and reconcile it against themselves. The whole commercial side — payment, documents, the goods table — was folded into the shipment record, and the deal pipeline was removed from the working process.

Pieces: warehouse tracking and thermal labels

A piece is a separate record for every physical unit inside a shipment. It has its own number, its own warehouse, its own delivery address and its own assigned owner. The warehouse supervisor receives and releases individual pieces, not an abstract shipment — so when twelve go out and eleven arrive, the discrepancy surfaces on a specific line rather than at the level of the whole consignment.

For pieces, iWeb built warehouse label printing straight from the portal to a thermal printer, 60 × 60 mm. The label carries the warehouse, the client company, the assigned manager, the piece count, the delivery address, the service type and a phone number. Numbering runs as "3 of 12": the numerator is unique to every label, the denominator is pulled from the record. The warehouse clerk sets the quantity and prints the batch as a single job instead of twenty separate operations in a third-party app.

Trip: truck, driver, route

A trip is a standalone entity with its own stages: forming, loading, en route, arrived, closed. The dispatcher builds a trip from ready shipments, assigns the truck and the driver, and manages the route. One trip collects dozens of shipments, and a single shipment may physically depart from the Bishkek warehouse or from any intermediate warehouse along the corridor.

This is where the project's most consequential architectural fork was — more on it below, in the section on rejected options.

Five documents in one click

The most visible win for the managers. Five documents print from a single shipment record:

• the transport order
• the invoice
• the completion certificate
• the contract
• the CMR international consignment note

The customer's company details are entered once and stored on the company record. From then on they flow into every document automatically — along with the contract number and date, the route, the amount and the consignment contents. iWeb also set up the signature and seal images: the director's signature and the company stamp render onto the print templates automatically, so an invoice reaches the customer ready to use, not via a scanner.

The CMR is a story of its own: rather than redrawing the note, iWeb took the client's existing blank form and embedded the fields directly into it. The international document stayed exactly what it was — it just fills itself in from the portal now.

The load manifest

The manifest is the list of every shipment travelling on a given trip. It used to be assembled in Excel from eight managers' spreadsheets. Now it is a configured view of the shipment list inside the portal: the same columns the spreadsheet had, but the data comes from the records and stays current on its own. No separate manifest system was built — none is needed, because a manifest is the trip's shipment list, not an object in its own right.

Shipment tracking on the website

The company website now offers tracking by tracking number. A customer enters their consignment's number and sees the shipment status and the truck's position on a map — without calling their manager. Position data comes from the driver's mobile app into the trip record, and from there to the public page.

It is the only module that serves people outside the company, and it is also the one that offloads the managers the most: the routine "where is my shipment" question, customers now answer themselves.

The mobile app

The app plays two roles. For drivers it sends geolocation and status updates straight from the road — what used to be settled by phone calls. For customers it shows their consignments and their movement from a phone, the same way the website does but without opening a page.

BI analytics

On top of the accumulated data, iWeb built profitability reports: what a trip earns, what a customer earns, and how both change over time. These numbers used to be calculated by hand and on request, so they only ever existed as one-off summaries. Now the executives open them in the portal.

Documents printed blank and raised no error

The most expensive find, measured in hours. Bitrix24 document templates substitute values by field codes, and a code can be written in two similar-looking forms. One of them — the one that looks more logical and matches how the field is named in the settings — does not work. And the generator shows no error and no warning: the document builds, opens, looks fine, and simply has blank lines where the data should be.

Until this surfaced through trial and error, every failing template looked like a problem with the field itself rather than with how its code was written. Once the working format was confirmed, all five documents were swept and brought to a single notation. The takeaway is simple: never accept Bitrix24 print templates on the evidence that "it generated" — check them field by field against a real record, not a test one.

The stamp and signature would not appear on the invoice

Signature and seal images in Bitrix24 require three conditions at once, and missing any one of them produces the same result — an empty space on the page. The signature and stamp images must be uploaded both to the company's details and to the company record itself. In the template, their place is marked not by a text code but by a placeholder image whose code is written into the image description. And at generation time, the "stamp and signature" option must be ticked.

Each of the three conditions looks like a small thing on its own. Together they add up to a day of debugging over nothing.

The field you must never rename

When tidying up fields it is easy to delete or rename something that looks like leftover clutter. In the warehouse part, one such field turned out to be structural: the shipment number is derived from it. Renaming it would have broken numbering retroactively across the whole database. The field was left as is and flagged, and the rest of the clean-up proceeded point by point, with every candidate double-checked.

A hundred pages of labels for the sake of one

The thermal printer prints a 60 × 60 mm page, and a standard print template is not designed for that format. The task sounded simple: the warehouse clerk enters the piece count and gets exactly that many labels, numbered "1 of 12", "2 of 12" and so on.

The solution ended up unconventional: a hundred-page template where the piece number is fixed on each page and the total is substituted from the record. The clerk prints the number of labels needed by setting a page range. Font size and margins took separate tuning: in early versions, long Russian-language addresses ran off the label — and this only showed up on the client's real data, because short test values fitted beautifully.

People, not software

Technically the portal was ready before everyone was using it. Some managers joined the training later than others, so the move to the new process stretched out: for a while, part of the work kept flowing into the old spreadsheets out of habit. iWeb started training in the second month of the implementation, without waiting for every module to be finished — and that is the right order. Teaching people after the whole system is delivered takes longer than teaching them as it appears.