Define the country, document and exchange rules first.
Product marking is not one universal configuration. Before integration, the project team identifies the relevant state systems, code and document types, response statuses and exception owners for the selected country.
ILLUSTRATIVE PROJECT BOUNDARY PROJECT SCOPE
PROJECT SCOPEUZSCOPEDISCOVERY
Official source Project specification Verifiable exchange
UZ
Product scenario available
Uzbekistan
External system
The agreed state product-marking system and electronic-invoice operator
Document
Electronic invoice and the related warehouse operations within the project scope
What is validated
Which codes, operations and responses belong to the agreed implementation scope
Decision owner
Finance or compliance together with IT
SCOPE
Agreement required
Selected project country
External system
State marking and fiscal systems for the selected country
Document
Only the agreed document and operation types
What is validated
Formats, mandatory fields, statuses, errors and controlled retry rules
Decision owner
The customer's compliance owner
DISCOVERY
Discovery comes first
New country
External system
Defined after official sources have been reviewed
Document
Not copied automatically from another market
What is validated
Legal applicability, technical protocol and operational readiness
Decision owner
The joint project team and the customer's authorised subject-matter experts
ITEM-LEVEL TRACEABILITY
A code moves through warehouse operations and documents without a manual break.
A code scanned at receipt remains linked to the item and its source document. The same history follows movements and shipment, while the external-system response returns a confirmed status or a structured rejection reason to the operation.
01Receipt
02Movement
03Shipment
04E-invoice
05System response
01
Receipt
Responsible role
Warehouse team
Control fact
The code is scanned and linked to the item, batch and receipt document
02
Movement
Responsible role
Warehouse-operation owner
Control fact
The code moves with its document between storage locations
03
Shipment
Responsible role
Warehouse and logistics
Control fact
The collected codes match the physical items being handed to the customer
04
E-invoice
Responsible role
Finance or fiscal role
Control fact
The item, quantity and codes agree with the warehouse operation
05
System response
Responsible role
Integration or exception owner
Control fact
The operation receives a confirmed status or structured rejection reason
RECONCILIATION BEFORE SUBMISSION
The e-invoice is assembled from the actual warehouse operation.
The pre-check covers more than quantity. Smartup compares the item, code identifiers, shipment composition and document details so a mismatch becomes visible before the external system responds.
ILLUSTRATIVE PRE-CHECKE-INVOICE · PRE-CHECK
DOC / SHIPMENT
SKUItem and unit of measure✓
CODEMarking codes✓
QTYQuantity and composition✓
DOCE-invoice details✓
SKU
Item and unit of measure
Data source
Product master and warehouse-document line
What is compared
Item identifier, unit of measure and agreed classification
State
The relationship is confirmed by project master data
CODE
Marking codes
Data source
Codes physically scanned while assembling the shipment
What is compared
Uniqueness, product ownership and eligibility for the operation
State
Each code is linked to a specific document line
QTY
Quantity and composition
Data source
The assembled shipment and scanned-code list
What is compared
The number of codes matches the physical units being shipped
State
A discrepancy is visible before document submission
DOC
E-invoice details
Data source
Customer, operation, warehouse document and project rules
What is compared
Required fields and relationships are present for the agreed scenario
State
The document is ready under the project exchange procedure
EXCEPTION REVIEW
Every deviation receives a reason, owner and safe next step.
A retry must not hide the original error. Smartup preserves the operation, external response and correction history, while the project procedure defines who may amend data and initiate another controlled exchange.
ILLUSTRATIVE EXCEPTION QUEUESTATUS · OWNER · NEXT STEP
MATCH
Code does not match the shipment
Signal
The document contains a code outside the physically assembled shipment
Evidence available for review
Scan event, item line, warehouse operation and document version
Owner
Picking or warehouse-document owner
REJECT
Document rejected
Signal
The external system returned a non-accepted status
Evidence available for review
Request, response, reason and the agreed response-status directory
Owner
Project finance or fiscal role
RETRY
Exchange temporarily unavailable
Signal
No confirmed response arrived within the window defined by the project procedure
Evidence available for review
Attempt time, technical status and absence of a business response
Owner
IT or integration owner
CLOSED
Correction confirmed
Signal
The external system accepted the corrected document
Evidence available for review
The original deviation, correction and final-response history
Owner
Project control role
READINESS FOR PRODUCTION EXCHANGE
Five conditions to validate before the first live shipment.
The launch is ready when country rules are translated into a testable specification, master data is reconciled, the exchange channel is observed, exception paths are rehearsed and decision ownership is explicit.
01
Country rules are documented
Official sources, operation types, documents, codes and responses are listed for the agreed project scope.
02
Master data is mapped
Items, units, partners, storage locations and external identifiers have confirmed owners.
03
The exchange is observable
Requests and responses expose status, time, identifier and diagnostic context without unnecessary data disclosure.
04
Scenarios are tested
The team verifies success, code mismatch, document rejection, unavailable exchange and corrected submission.
05
Owners are assigned
It is clear who corrects warehouse facts, documents and integration errors, and who confirms exception closure.
For the compliance decision
Objections to resolve
Code and fiscal-document rules must be confirmed for the agreed country and project scope before productive exchange.
Can one marking configuration be used in every country?
No. Terms, documents, statuses and exchange rules depend on the agreed country. Confirm them separately within the project scope.
Does the module replace ERP or full tax accounting?
No. It supports the agreed marking-code and fiscal-document process; master-data and accounting ownership follow the project architecture.
What happens when a code and document disagree?
The operation should become a controlled exception with a reason, log, owner and an agreed-country rule for correction or safe resubmission.
Platform scale
The module runs on Smartup’s shared data model
Shared customer, outlet and SKU master data connects each operation with sales, inventory, finance and analytics.
800+
active mid-sized and large companies in Central Asia
28 000+
daily active users
30+
confirmed integrations
Smartup · FMCG / CPG
See the module on your own processes
In 30 minutes, we will review your current workflow, loss points, launch data and the first controlled scenario.