经营特产店最怕的不是卖不动，而是数据断档。门店收银系统里明明显示某款笋干只剩三包，仓库端却还在按上周的旧数据备货；旅游旺季订单一多，人工统计Excel表格根本来不及汇总，补货指令发出去半天得不到回执。要解决这类问题，并不一定非要上昂贵的ERP系统，用R语言就能搭一套轻量级的进销存与物流管理网络，把门店端的数据采集、中央服务器的数据汇总、仓库端的补货调度串成一条完整链路。
整体架构：门店端、服务端与仓库端如何分工
这套方案把系统拆成三个角色。门店端负责销售数据的录入与上报，可以是一台收银电脑上运行的shiny应用，店员扫码或手输商品编码即可完成记录；服务端是一台常驻运行的R进程，通过plumber包暴露REST接口，接收各门店上报的流水数据，同时向仓库端下发补货任务；仓库端定时拉取补货清单，结合配送优先级安排发货。
选这套架构的理由很简单：R语言在数据处理上的表达力极强，data.table处理几十万行订单流水毫不吃力，而shiny和plumber又能让不懂代码的店员和仓管员通过网页界面完成日常操作，学习成本几乎为零。相比直接购买商用系统，这套方案的硬件要求只有一台能跑R的服务器，月成本可以压到很低。
数据流向设计成单向上报、按需拉取：门店每完成一笔交易就异步推送到服务端，即使网络抖动也可以先落本地缓存，等网络恢复后批量补传。这种弱网容错设计对地处山区或景区、网络条件一般的特产门店尤其重要。
用shiny搭建门店端录入界面并完成数据上报
门店端的核心是一个简洁的shiny应用。界面上只放三个输入项：商品编码、数量、会员手机号（可选），减少店员的操作负担。提交后，应用会调用httr的POST函数，把这笔流水以JSON格式发给服务端。
library(shiny)
library(httr)
library(jsonlite)
# 服务端接口地址，部署后替换为实际服务器IP
server_url <- "http://192.168.0.1:8000/sales"
ui <- fluidPage(
titlePanel("特产店销售录入"),
textInput("product_id", "商品编码"),
numericInput("qty", "数量", value = 1, min = 1),
textInput("phone", "会员手机号（可选）"),
actionButton("submit", "提交"),
verbatimTextOutput("result")
)
server <- function(input, output, session) {
observeEvent(input$submit, {
record <- list(
product_id = input$product_id,
qty = input$qty,
phone = if (input$phone == "") NA else input$phone,
store_id = "STORE_01",
ts = format(Sys.time(), "%Y-%m-%d %H:%M:%S")
)
resp <- tryCatch({
POST(server_url, body = record, encode = "json", timeout(5))
}, error = function(e) NULL)
if (is.null(resp) || status_code(resp) != 200) {
# 上报失败，先写入本地缓存，稍后批量补传
cache_file <- "pending_sales.rds"
old <- if (file.exists(cache_file)) readRDS(cache_file) else list()
saveRDS(c(old, list(record)), cache_file)
output$result <- renderText("网络异常，已本地缓存，稍后自动补传")
} else {
output$result <- renderText("上报成功")
}
})
}
shinyApp(ui, server)这段代码的关键在于失败兜底逻辑。很多门店的网络并不稳定，如果提交失败就直接丢弃数据，月底对账时就会出一堆糊涂账。所以代码里把失败的记录存进pending_sales.rds，再配合一个定时任务（可以用taskscheduleR或者系统的cron）每五分钟重试一次缓存队列，直到全部补传成功为止。实际部署时建议给每条记录加一个UUID，服务端收到重复数据时按UUID去重，避免补传机制造成流水重复入库。
服务端用plumber接收数据并做汇总分析
服务端用plumber写的REST接口非常精简。收到销售流水后先做基础校验（商品编码是否存在、数量是否为正），然后追加写入data.table，同时触发库存检查逻辑：如果某商品在所有门店的预估库存低于阈值，就生成一条补货任务。
library(plumber)
library(data.table)
library(jsonlite)
# 商品目录与当前库存
products <- data.table(
product_id = c("SP001", "SP002", "SP003"),
name = c("高山笋干", "野生蜂蜜", "手工腊肉"),
stock = c(120, 60, 45),
threshold = c(50, 30, 20)
)
sales_log <- data.table() # 销售流水表
replenish_tasks <- data.table() # 补货任务表
#* 接收门店上报的销售流水
#* @post /sales
function(req) {
body <- req$body
if (is.null(body$product_id) || !(body$product_id %in% products$product_id)) {
return(list(status = 400, msg = "无效商品编码"))
}
if (!is.numeric(body$qty) || body$qty <= 0) {
return(list(status = 400, msg = "数量不合法"))
}
# 扣减库存并记录流水
products[product_id == body$product_id, stock := stock - body$qty]
sales_log <- rbind(sales_log, as.data.table(body))
# 检查是否触发补货
low <- products[stock < threshold]
if (nrow(low) > 0) {
for (i in seq_len(nrow(low))) {
pid <- low$product_id[i]
if (nrow(replenish_tasks[product_id == pid & status == "pending"]) == 0) {
replenish_tasks <- rbind(replenish_tasks, data.table(
product_id = pid, qty = 100, status = "pending",
created = Sys.time()
))
}
}
}
assign("products", products, envir = .GlobalEnv)
assign("sales_log", sales_log, envir = .GlobalEnv)
assign("replenish_tasks", replenish_tasks, envir = .GlobalEnv)
list(status = 200, msg = "ok")
}
#* 仓库端拉取待处理的补货任务
#* @get /replenish
function() {
as.list(replenish_tasks[status == "pending"])
}
pr("plumber.R") %>% pr_run(port = 8000)这里有个容易踩的坑要提醒：plumber默认每个请求会触发重新读取环境，直接修改函数内的局部变量并不会持久化。上面的代码用assign把更新后的表写回全局环境，是为了演示方便；生产环境更稳妥的做法是把流水落到SQLite数据库（R的RSQLite包配合DBI即可），每次请求直接读写数据库，这样即使服务器重启数据也不会丢。
汇总分析层面，data.table的分组统计能力可以快速产出经营日报：按商品统计当日销量、按门店统计营收、按时段分析客流高峰。这些报表同样可以用一个shiny页面挂载在服务端，供老板随时在手机浏览器里查看。
物流管理：从补货任务到配送路径
补货任务生成之后，剩下的问题是仓库怎么送。特产店往往一仓对多店，配送顺序直接影响油耗和时效。最直接的思路是按紧急度排序：库存越接近零的门店优先送；如果想要更精细一点，可以引入简单的贪心算法解决旅行商问题的近似解——每次从当前位置出发，挑选距离最近的下一个待补货门店，直到全部送完。
library(data.table)
# 门店坐标（经纬度可用geosphere计算距离）与紧急度
stores <- data.table(
store_id = c("STORE_01", "STORE_02", "STORE_03", "STORE_04"),
lng = c(118.12, 118.30, 117.95, 118.45),
lat = c(24.48, 24.75, 24.30, 24.60),
urgency = c(3, 5, 1, 2) # 数值越大越紧急
)
# 简单的欧氏距离近似（小范围场景够用）
dist <- function(a, b) sqrt((a[1]-b[1])^2 + (a[2]-b[2])^2)
plan_route <- function(stores, warehouse = c(118.20, 24.55)) {
remaining <- copy(stores)
route <- character(0)
current <- warehouse
while (nrow(remaining) > 0) {
# 先处理紧急度最高的门店中，距离最近的一个
max_urg <- max(remaining$urgency)
cand <- remaining[urgency == max_urg]
dists <- apply(cand[, .(lng, lat)], 1, function(x) dist(x, current))
pick <- cand[which.min(dists)]$store_id[1]
route <- c(route, pick)
current <- unlist(remaining[store_id == pick, .(lng, lat)])
remaining <- remaining[store_id != pick]
}
route
}
plan_route(stores)这种贪心策略不会给出数学最优解，但对四五家门店的小规模配送来说，结果和最优解差距很小，而计算量几乎可以忽略。如果门店数量增长到十家以上，可以考虑切换到更正式的求解器，或者用遗传算法做近似优化。此外，每次配送完成后，仓库端调用服务端的一个确认接口，把补货任务标记为completed并回增库存数字，整个数据闭环就闭合了。
整套系统跑起来之后，店主在手机上就能看到每家门店的实时库存、当日销量和待配送任务，仓库端不再需要人工对账。R语言在这类中小规模业务场景下的性价比相当突出：开发周期短、依赖少、维护简单，一个人利用业余时间就能完成从搭建到上线的全过程。如果后期业务规模扩大，再平滑迁移到更重的技术栈也不迟，前期沉淀的数据结构和业务逻辑都可以作为迁移的蓝本。