Creating a New Delivery

A delivery in wallmarkets is a dated record of what you are sending, where it is going, and what that shipment is worth.

That sounds simple, but this is one of the places where small input mistakes turn into real operational confusion later. If the wrong branch is selected or the wrong quantity is entered, the bad record follows the rest of the workflow.

The point of the delivery form is not just to log work. It is to create a clean source of truth before the truck leaves.

Before you start

You will move faster if these pieces already exist:

• the product catalog has the items you actually deliver
• the supermarket and branch are already set up
• the unit prices on those products are worth trusting

If any of those are still rough, fix them first. A delivery record is only as useful as the catalog and destination data behind it.

Open the form

Go to Deliveries and click New Delivery.

The form is built around four decisions:

1. where the shipment is going
2. which branch it belongs to
3. which products are on it
4. what date the delivery is scheduled for

Keep the first pass practical. One real delivery with clean data is better than a bigger record filled with guesswork.

Choose the destination carefully

Start with the supermarket, then confirm the branch.

This matters more than teams expect. Chain names are familiar, but branches are where delivery mistakes usually hide. A delivery tied to the wrong branch still looks plausible on screen while being wrong in the field.

Before moving on, confirm:

• the supermarket is the correct account
• the branch is the receiving location you actually mean
• the branch details are specific enough for the team to recognize

If the branch list is incomplete, add or fix the branch record first instead of working around it.

Add products line by line

Each product row captures three things that matter later in reporting and returns:

• product
• quantity
• unit price

wallmarkets validates that the product belongs to your business and that both quantity and price are greater than zero. That is useful, but it is not enough on its own. You still need to check that the row matches what is physically going out.

The clean way to work here is:

• add only products that are actually on this delivery
• use the real quantity, not a placeholder
• review the unit price before submitting

If a product is missing from the picker, stop and add it in Managing Products instead of substituting something close.

Pick the delivery date deliberately

Delivery dates cannot be in the past. In day-to-day use that means the date field is doing two jobs:

• it keeps the record operationally relevant
• it gives your reports and history the right timeline later

Use the date you want the delivery record to represent, not the date you happened to be doing admin work.

Review the record before you submit it

The best time to catch a mistake is before the delivery exists.

Do a short review of:

• destination supermarket
• branch
• product list
• quantities
• prices
• delivery date

This only takes a moment, and it prevents the most common cleanup work later: correcting bad quantities, explaining mismatched totals, or creating returns that were really just data-entry mistakes upstream.

What happens after creation

When the form is submitted successfully, the delivery appears in your delivery list and gets its own detail page.

That detail page is where the record becomes useful. You can:

• review the delivery information and product lines
• download the delivery as a PDF
• print a receipt-style copy
• create a return directly from the original delivery

That last point matters. Deliveries and returns stay connected in wallmarkets, which is why getting the original delivery right is so important.

What the system validates

wallmarkets checks the basics before saving the record:

• the supermarket must belong to your business
• the branch must belong to that supermarket
• at least one product line must be present
• quantity must be greater than zero
• price must be greater than zero
• the delivery date cannot be in the past

Validation keeps obviously broken records out. It does not replace operational judgment. A technically valid delivery can still be the wrong one if the branch or quantities are off.

Common mistakes

Treating branch selection as a minor detail

It is not. Branch choice affects what the team sees, what reports group together, and which delivery a return will point back to later.

Copying quantities from an old spreadsheet without checking them

This is one of the fastest ways to create preventable returns or reconciliation work.

Submitting before the catalog is clean

If names, prices, or categories are still inconsistent, the delivery record becomes harder to trust immediately.

A good operating habit

Create the delivery as close as possible to the real plan, then treat the detail page as the official record for that shipment.

That one habit does a lot of work:

• reports become more reliable
• return records stay easier to interpret
• the team has one place to check what was actually sent

Related guides

• Setting up your first delivery
• Tracking deliveries
• Delivery reports and analytics