Delivery Summary
Delivery counts and values over the selected period, with direct access back into the underlying records.
Open delivery guideGuides, examples, and reference paths for running deliveries, returns, products, B2B onboarding, supermarket accounts, reports, and integrations in wallmarkets.
Browse by workflow
Short paths first, deeper reference below. Pick the workflow that matches the job in front of you.
Use this section when you want the shortest reliable route from a new account to one real delivery record that can be reviewed, printed, and reported on.
wallmarkets helps suppliers keep deliveries, returns, products, and supermarket accounts in one working system. Use it to create clean delivery records, link returns back to original shipments, and review the numbers in reports and analytics.
Use real product, branch, quantity, and price data so the rest of the workflow has something useful to show.
The fastest confidence comes from one boring but accurate record, then one return if your team needs it.
You get a delivery detail page that can feed printing, exports, returns, reporting, and later review.
Use the first delivery to prove the workflow with real data, not to stress-test every edge at once.
On mobile devices, you can install wallmarkets as a Progressive Web App (PWA) for faster repeat access and limited cached browsing when connectivity is shaky. Learn how →
Create clean shipment records that answer where goods went, what was included, and what should happen next if something comes back.
Navigate to Deliveries > New Delivery. Select the target supermarket and branch, add one or more products with quantities, choose a delivery date, and submit.
The resulting detail page becomes the source record you can review, print, export, or use as the starting point for a linked return later.
supermarket: E-mart
branch: Central Branch
delivery_date: 2026-03-15
lines:
Whole Milk 1L x 50 @ 2850
Greek Yogurt 500g x 30 @ 4200
The important part is not the format itself, but that destination, quantities, and prices are correct before the record is saved.
The current workflow is centered on a clean record rather than a deep status machine. In practice, teams move between the list view, the detail page, and any linked return records.
| Dashboard Field | Operational Meaning | Decision Impact |
|---|---|---|
| Date | When the delivery record is scheduled and when it was created | Useful for reviewing timing and period activity |
| Destination | Supermarket and branch | This is where branch-level mistakes usually surface first |
| Value | Total delivery value from the line items | Helps you notice outsized shipments quickly |
| Completed / Return(s) | Whether the delivery currently stands alone or already has linked return records | A fast signal for follow-up work |
The deliveries page is a dated working list. Use it to open records, export CSV, review values, and spot which deliveries already have linked returns. When something needs explanation, move into the delivery detail page rather than trying to infer too much from the table alone.
Keep returned goods attached to the original delivery so the story remains readable in operations, finance, and reporting.
Go to Returns > New Return, or start from a delivery detail page. Select the original delivery, confirm the product(s) and quantities being returned, choose the return date, and save the record.
Every return stays linked to the original delivery, which is what keeps the history readable later in reporting and follow-up work.
| Validation Check | Rule Enforced | Risk Prevented |
|---|---|---|
| Delivery scope | The selected delivery must belong to the current business | Prevents returns from being linked to the wrong account |
| Return date | It cannot be before the delivery date or in the future | Keeps return history chronological and believable |
| Quantity | Returned quantity cannot exceed what was delivered minus any earlier returns | Stops teams from over-returning the same shipment on paper |
| Price | Returned lines must still carry a positive unit price | Keeps return value meaningful in reports and exports |
Each return keeps a direct relationship to the original delivery and can be reviewed, printed, or downloaded as a PDF. That linked structure is what makes later analysis and reconciliation easier than trying to track returns as free-floating notes.
The reporting views make it easier to read return totals beside delivery totals, then filter deeper by supermarket and category in analytics when a pattern needs explanation.
Make the catalog trustworthy before deliveries use it. Product data should be boring, consistent, and easy to import in batches.
Each product has a name, weight, price, and category. Products are assigned a unique sequential ID used across deliveries, returns, and reports. Add products individually or import a batch via CSV.
Edit existing products from the product detail page. Changes to price or weight apply to future deliveries only — historical records are preserved.
| API Field | Value Type | Required? | Field Meaning |
|---|---|---|---|
| name | string | Product display name | |
| weight | decimal | Weight in kilograms | |
| price | decimal | Unit price | |
| category | string | User-defined grouping | |
| sequential_id | integer | auto | Unique, system-assigned |
Bulk-add products by uploading a CSV file. The importer validates each row and reports any errors before committing.
name,weight,price,category
"Whole Milk 1L",1.03,2850,"Dairy"
"Greek Yogurt 500g",0.52,4200,"Dairy"
"Orange Juice 2L",2.10,5600,"Beverages"
Organize products into categories (e.g. Dairy, Beverages, Frozen) for easier filtering in the delivery form and for category-level reporting. Categories are user-defined — create whatever groupings make sense for your business.
Separate chains from branches so your team can deliver to the right physical place instead of relying on vague account names.
Each supermarket account represents a chain you deliver to. Within that account, you can register branches with their own address and contact details. This structure keeps deliveries and returns tied to the right receiving location instead of flattening everything into one chain-level record.
Branch records are most useful when they contain the details your team will actually rely on during delivery creation and later review.
name: Central Branch
address: Peace Avenue 10
contact_person: Receiving Manager
phone: +976-...
email: central@example.com
The sharper the branch data, the easier it is to avoid destination mistakes later.
Use the supermarket and branch pages to keep names, addresses, and contacts accurate. Clean branch data pays off later in delivery creation, returns, and reporting.
Use B2B onboarding when a supermarket wants to receive product pitches online, or when a local supplier wants to pitch real catalog items into supermarket shelves.
B2B onboarding turns shelf access into a tracked workflow. A supermarket owner can open a buyer portal, publish what each location is willing to receive, review local supplier pitches, message the supplier, approve or decline the pitch, and start the first stock request. A supplier can open the same portal from the supplier side, send a shelf pitch with catalog proof, then coordinate requests, deliveries, invoices, and payment follow-up after approval.
The buyer path starts at B2B onboarding, enables the portal, and sends the owner to shelf intake so locations are ready before suppliers pitch.
The supplier path can start from the public B2B intake directory, then uses Find Supermarkets to send product proof, hero products, launch terms, and contact details.
Every invite, pitch, note, message, approval, decline, stock request, invoice, and admin review stays attached to the B2B record.
Use this path for an eMart-style owner or category buyer who wants to receive pitches from local brands and decide what belongs on physical shelves.
Use this path for a food producer, packaged-goods brand, or wholesaler that already has products and wants to show supermarket buyers why the products deserve shelf space.
| Onboarding Moment | What Happens | Record Created Or Updated | Owner Decision |
|---|---|---|---|
| Enable B2B | The business switches from normal logistics only into the B2B portal. | Business b2b_enabled is set, onboarding step is marked complete | Choose buyer path, supplier path, or use both |
| Shelf intake | The supermarket states what it can receive and what proof it expects. | Supermarket intake fields, contact, windows, documents, notes | Make the location pitch-ready |
| Supplier pitch | A supplier asks for shelf access and attaches its catalog story. | Partnership row plus pitch package audit details | Review, message, note, approve, or decline |
| Approved pitch | The supplier is trusted enough to begin shelf coordination. | Partnership status changes to active | Create the opening stock request |
| Opening order | The buyer requests initial quantity for selected products. | Stock request with product, supermarket, quantity, and requested-by user | Approve, reject, convert to delivery, invoice, and track payment |
Use reports to compare movement, returns, and value without turning every question into spreadsheet reconstruction.
The main dashboard gives you the fast read most teams need first: revenue, net revenue, deliveries, and returns over the selected period. The point is not to admire the cards. It is to notice when one of them starts telling a different story from the rest.
Delivery counts and values over the selected period, with direct access back into the underlying records.
Open delivery guideReturn counts and values beside deliveries, so you can see which accounts or periods are generating drag.
Open return guideRead gross movement beside returns and net value so the period makes financial sense, not just operational sense.
Open dashboard guideUse product and category views to see where value is concentrated and which items keep coming back as return work.
Open analytics guideNavigate to Reports in the sidebar, set the date range, and review deliveries and returns together first. When you need a deeper explanation, open the analytics dashboard and filter by supermarket or category.
GET /api/dashboard/stats?range=30d
{
"revenue": 12450000,
"net": 11200000,
"deliveries": 156,
"returns": 8,
"period_change": "+12.3%"
}
Keep ownership, API keys, billing expectations, and account settings clear so operations do not depend on mystery access.
Update your name, company, email, avatar, and username in Account Settings. The same page also gives you password change, language preferences, notification toggles, privacy links, and the account deletion action.
| Product Area | Current Coverage | Recommended Practice |
|---|---|---|
| Business data scope | Deliveries, returns, products, and supermarkets are tied to the current business context | Check business context first when something seems to be missing |
| Account settings | Profile, password, language, privacy links, and account deletion live in the signed-in account settings | Keep ownership and owner email clear inside the team |
| API keys | Keys are created and revoked from the account that owns them | Use separate named keys per integration and revoke stale ones quickly |
| Team control | The product is simpler today than a full enterprise role-management console | Do not build internal process around UI that is not actually present yet |
Generate named API keys in Account Settings > API Keys. Copy the key when it is shown, store it safely, and revoke it when the integration no longer needs access.
Key name: Production ETL
Rate limit tier: standard
Best practice: one key per integration
Action when retired: revoke immediately
wallmarkets offers plan-based access, but not every account exposes a full self-serve billing workspace directly in the app. Treat billing changes as owner-level work and use the billing guide when the path needs clarification.
Explore our step-by-step guides in the Help Center or dive into the API Reference for advanced integrations.