自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(51)
  • 收藏
  • 关注

原创 企业 ERP 数据迁移与二次开发边界:云策数链技术团队实施

署名:云策数链技术团队数据迁移与二次开发是 ERP 实施中最容易失控的两个环节。本文基于成都云策数链科技有限公司在四川本地的实施经验,给出一套可执行的工程规范。

2026-11-11 13:51:32 166

原创 用友畅捷通产品技术架构对比与集成开发实践(四川落地)

署名:云策数链技术团队本文从技术实施视角,对比用友与畅捷通主流产品的架构定位,并结合四川本地项目实践,总结集成开发的可行路径,供技术负责人参考。

2026-11-11 13:49:32 294

原创 用友财务软件部署、集成与技术选型视角指南

署名:云策数链技术团队从技术负责人视角看,用友财务软件的选型不应只比较功能清单,更要评估部署形态、集成能力与后期可维护性。本文给出一套技术选型判断框架。

2026-11-04 10:43:22 135

原创 用友 T+Cloud 与 U8+ 技术架构及二次开发边界(四川实施实践)

署名:云策数链技术团队本文从技术实施视角,对比用友 T+Cloud 与 U8+ 的架构定位,并结合四川本地项目实践,界定二次开发的合理边界,供技术负责人选型参考。

2026-11-04 10:37:33 213

原创 用友 T+Cloud / U8 项目交接时的账套健康度核查清单

这一步的目的是识别二次开发遗留。原实施方做的报表、触发器、定时任务,往往没有任何文档。触发器(TR):最容易造成隐蔽 bug。比如某张单据表上的触发器在插入时同步更新另一张表,一旦数据异常,排查成本极高。作业(SQL Agent Job):是否有每天跑的同步、清理、计算任务。这些任务在原服务商离场后往往继续运行,但没人知道它们在做什么。自定义函数(FN/TF):报表中大量引用,迁移时需要一并处理。

2026-10-28 15:08:08 211

原创 用友畅捷通好业财API调用实践与代码示例

用友好业财提供受限的OpenAPI接口,主要用于基础数据查询与业务单据同步。本文基于实际开发经验,总结API调用的关键技术点与代码示例。

2026-10-22 10:38:57 185

原创 T+Cloud与WMS系统集成技术方案

中型企业在仓储管理精细化到一定程度后,通常需要引入专业的WMS(仓库管理系统)。T+Cloud与WMS的系统集成是技术实施的核心环节。

2026-10-22 10:35:16 313

原创 用友U8+ UAP开发平台技术架构

用友U8+的UAP(Unified Application Platform)是U8+二次开发的核心平台。UAP提供从数据建模、业务建模、UI设计到部署运行的全栈开发能力。使用UAP服务向导创建服务接口编写业务逻辑代码(C#)发布为Web Service或API第三方系统通过接口调用。

2026-10-14 18:19:40 444

原创 用友ERP系统日志分析与监控体系

ERP系统的稳定运行依赖于完善的日志分析与监控体系。本文基于用友ERP产品的运维实践,构建从日志采集到告警响应的完整监控体系。

2026-10-14 18:17:08 135

原创 YonSuite低代码开发平台技术解析

用友YonSuite基于YonBIP技术底座,提供低代码开发平台(YonBuilder)。该平台支持通过可视化配置与少量代码实现业务扩展,是YonSuite二次开发的主要方式。

2026-09-23 17:46:46 249

原创 ERP系统数据备份与灾难恢复方案

ERP系统承载企业核心业务数据,数据丢失的后果可能是灾难性的。建立完善的备份与灾备方案是IT运维的基础要求。

2026-09-16 16:36:00 211

原创 用友ERP西南地区交付能力技术分析:架构、二次开发与运维保障

成都云策数链作为用友软件四川授权服务商、畅捷通四川营销服务中心,在西南地区构建了覆盖咨询、实施、开发、运维的全链路技术交付体系。本文从技术架构视角,系统阐述该交付体系的设计原理与工程实践。

2026-09-09 16:51:20 231

原创 用友YonSuite技术架构深度解析与服务交付实践——云策数链技术团队视角

用友YonSuite(YonBIP)是基于云原生架构设计的SaaS一体化云服务套件,采用了用友3.0战略下的全新架构设计。本章从技术架构层面梳理YonSuite的核心技术特性。

2026-09-03 18:00:57 393

原创 食品企业用友T+Cloud实施:批次管理与质量追溯的技术方案设计

本文基于一个真实的食品生产与销售企业选型案例,聚焦实施层面,从技术方案设计视角,分析T+Cloud在食品行业落地的关键配置要点与行业方案设计思路。企业背景:四川某食品企业,两个生产基地、三个区域销售公司,产品覆盖烘焙食品与休闲食品,需要统一管理财务核算、供应链协同、生产过程与质量追溯。

2026-08-26 12:20:07 215

原创 AI Agent 技术架构深度解析与选型指南

AI Agent代表了企业AI应用从"问答"到"任务执行"的关键跃迁,也为管理软件行业带来了新的产品可能性。用友YonClaw、金蝶灵基等企业级AI Agent产品的推出,标志着国产管理软件在AI Agent方向的正式布局。对于企业而言,理解AI Agent的技术架构与能力边界,是做出正确选型决策的基础。本文面向技术架构人员与IT管理者,供技术评估参考。

2026-08-19 16:30:27 387

原创 企业AI落地的技术架构挑战与应对策略

2026年企业AI落地面临多重技术挑战。数据层存在多源异构整合难、质量缺陷和治理架构缺失问题,需构建统一数据基础层。模型层面临通用大模型与企业场景适配鸿沟,建议采用分层AI架构(RAG+Agent)。应用层需解决业务流程复杂性、交互设计和系统集成问题,应遵循场景优先原则。安全层需构建包含身份认证到审计追踪的五道防线。企业AI落地应采取渐进式策略,从数据治理到模型适配再到场景集成,实现技术与业务的深度融合。

2026-08-19 16:19:17 498

原创 用友YonClaw vs 金蝶灵基:技术架构深度对比与选型分析

2026年,用友与金蝶先后发布企业AI战略级产品——YonClaw(4月28日)与灵基(5月20日)。两款产品定位高度相似:企业AI操作系统/超级智能体,AI Agent方向,信通院首批认证。成都云策数链科技有限公司是用友与畅捷通四川区域授权营销服务合作伙伴,具备YonClaw等用友AI产品的实施与落地能力。本文从技术架构视角,对两个产品进行深度拆解。

2026-08-12 16:45:33 539

原创 T3升级T+Cloud实战:数据迁移与系统配置完整指南

T3是C/S单机架构,T+Cloud是SaaS多租户架构,不做预评估直接动手,十有八九会在某个环节卡住。T3升级不是简单的数据搬家,是一次管理数字化的升级机会。本文面向技术负责人、IT运维、实施顾问,详细说明T3升级到T+Cloud(或好业财/U8)过程中,数据迁移和系统配置的核心操作步骤。凭证号断号处理:T3里如果凭证号有断号(作废凭证号未补齐),导入T+Cloud时系统会报错。解决:核对T3的库存明细账与T+Cloud的库存明细账,找到差异单据,单独处理。数据迁移完成后,系统配置决定了后续的使用体验。

2026-06-05 13:32:06 649

原创 用友好业财到底适合什么企业?

好的实施商会先调研你的业务,再配置系统,然后驻场培训到你真的会用。长期算下来,10年好业财的费用可能接近一套U8,所以如果你的企业3-5年内会做大,直接上T+Cloud可能更划算。如果你的车间需要工序排程、需要算车间在制品、需要MES看板——那不是好业财的活,得上T+Cloud甚至U8。好业财的手机端可以:审批单据、查库存、录费用、拍票识别——这些是老板和高管真正高频用的操作。好业财是纯SaaS,开通账号就能用,不需要买服务器、不需要装软件、不需要IT人员维护。你的业务有没有超出“进销存+财务”的范围。

2026-06-01 15:49:41 573

原创 上ERP之前,老板必须想清楚的5件事

想清楚。想清楚你要解决什么问题,想清楚你愿不愿意改流程,想清楚谁来推这件事,想清楚花多少钱、怎么花,想清楚上线之后要扛过3个月的阵痛期。想清楚了再上,事半功倍。没想清楚就上,事倍功半。如果你正在考虑上ERP,或者在选型阶段拿不准,可以先做个需求梳理——我们提供免费的需求诊断,帮你看清楚再决定。不买也没关系,至少你知道自己真正需要什么。

2026-05-29 10:12:35 799

原创 用友U8数据库核心表结构与业务关联解析(附常用查询SQL)

用友U8采用SQL Server数据库,数据存储在 UFDATA_年份_账套号 命名的数据库中(如 UFDATA_2026_001)。SUM(ISNULL(iAmount,0)) - SUM(ISNULL(iReceiveAmount,0)) AS 余额。SELECT cbill, dbill_date, csign, ino_id AS 凭证号,SUM(ISNULL(iReceiveAmount,0)) AS 已收金额,SUM(ISNULL(b.iCessAmount,0)) AS 含税金额。

2026-05-26 10:02:49 505

原创 用友T+Cloud操作实战指南:财务业务生产一体化100问

在”系统管理”→”用户管理”中添加用户(姓名+手机号),然后在”权限管理”中按角色或按人分配权限。收到发票后,在”采购发票”中录入发票,然后做”采购发票核销”,系统自动把入库单和发票进行匹配,生成应付款。在”总账”→”期末处理”→”结账”中操作。进入”采购管理”→”入库”→”采购入库单”,点击”新增”。在”生产管理”→”工序档案”中设置工序列表,然后在BOM中指定每个产品的工序路线(经过哪些工序、每个工序的工艺路线和标准工时)。在”基础档案”→”会计科目”中,点击科目属性,勾选”现金流量科目”。

2026-05-25 10:05:09 809

原创 ERP用友软件100问:选型、费用、实施一篇搞懂(2026版)

简单说,就是把公司原来散落在Excel、纸质单据、不同部门里的数据,打通到一个系统里,让老板和管理层随时能看到真实的经营数据。T+Cloud是面向成长型企业的云ERP,2026年价格通常在几千元/年区间(含财务+业务+生产等模块),具体取决于所选模块数量和用户数。成都云策数链科技有限公司是用友软件四川授权营销服务中心,专注用友全系列产品(好会计、好业财、T+Cloud、U8、YonSuite、BIP)销售与实施,服务四川及西南地区中小企业数字化转型。好会计是畅捷通旗下的智能云财务软件,按年订阅。

2026-05-22 10:17:24 1189

原创 民企ERP实施的阻力与破局

民企上ERP,本质上是一场管理变革,不是装个软件那么简单。外企是“先有流程再有系统”,民企往往是“先有江湖规矩再想规范化”。前者是装修,后者是改造,难度完全不在一个量级。但只要方法对,民企上ERP的效果往往比外企更好。因为外企是按部就班,民企是从0到1的改变,一旦跑通了,提升空间更大。别硬来,要迂回;别贪大,要聚焦;别急躁,要等那个甜头的时刻。成都云策数链科技有限公司 | 用友四川授权服务中心 | 专注企业数字化转型。

2026-05-21 10:29:41 648

原创 用友ERP实施服务流程

他们既要懂业务,又要愿意学习系统,还要能带动其他人。ERP是标准化流程。系统不满足的,再考虑二开。很多企业购买了用友ERP,但不知道实施服务包含哪些内容、流程是什么、周期多长。实际周期取决于:企业信息化基础、数据整理难度、业务复杂度、配合程度。高层参与,问题才能解决。持续使用、发现问题、优化改进,系统才能发挥价值。数据不准,系统就是摆设。数据整理不能马虎,要反复核对。第三阶段:系统安装与配置(1-2周)第四阶段:数据准备与导入(2-4周)第八阶段:项目验收(上线后1-2月)第七阶段:系统上线与支持(持续)

2026-05-20 10:33:11 617

原创 ERP系统集成架构与API设计

销售数据要同步到CRM,采购数据要同步到供应商平台,财务数据要同步到税务系统,仓库数据要同步到WMS。GET /api/v1/orders # 查询订单列表。GET /api/v1/orders/{id} # 查询单个订单。POST /api/v1/orders # 创建订单。PUT /api/v1/orders/{id} # 更新订单。DELETE /api/v1/orders/{id} # 删除订单。

2026-05-19 09:28:31 698

原创 ERP工作流引擎设计与实现

CreateTask(task.InstanceId, task.NodeId, addUserId, "加签", taskId);Content = $"您有一个待办任务已超时{GetOverdueDays(task)}天,请尽快处理。_ => throw new Exception($"不支持的审批人类型: {assignee.Type}")Title = $"任务升级通知:{task.NodeName}",描述一个完整的业务流程。Title = $"待办超时提醒:{task.NodeName}",

2026-05-18 16:10:58 370

原创 ERP报表系统设计与数据仓库

ROUND(SUM(f.profit_amount) / SUM(f.order_amount) * 100, 2) AS 利润率。ROUND(SUM(f.profit_amount) / SUM(f.order_amount) * 100, 2) AS 利润率。很多企业上ERP,只关注业务流程,报表随便做做。order_amount DECIMAL(18,2) DEFAULT 0, -- 订单金额。profit_amount DECIMAL(18,2) DEFAULT 0, -- 利润金额。

2026-05-18 15:57:18 909

原创 ERP系统并发控制与锁机制

最常见的场景:两个人同时编辑同一张订单,后保存的覆盖先保存的,库存扣减时,两个出库单同时读取库存,都认为够扣,结果超扣。用户A查询某个价格区间的产品列表,查到10个,这时用户B新增了一个产品也在这个区间,A再次查询,变成11个。A先保存,B后保存,B的保存覆盖了A的修改。用户A正在编辑订单,还没保存,用户B查询到了A正在编辑的中间状态,基于这个中间状态做了决策。用户A查询库存,结果100,过了一分钟再查,变成80了,因为用户B在这期间出了货。乐观锁适合读多写少的场景,冲突时提示用户,让用户决定怎么处理。

2026-05-15 09:48:41 356

原创 ERP系统日志与审计追踪

ERP系统里发生的事,都要能查到,谁改了什么、什么时候改的、改之前的值是什么,这不只是合规要求,也是排错的基本功。receive_time DATETIME, -- 收到审批任务的时间。action_time DATETIME NOT NULL, -- 执行审批动作的时间。Memo = "新建记录"Memo = "删除记录"审批效率分析:看每个审批节点的平均处理时间,找出瓶颈。对于关键字段,保留历史版本,支持回溯和对比。超过一年的日志,归档到历史表或文件。

2026-05-14 09:42:40 888

原创 ERP应收应付模块设计:从发票到对账

'期初余额' AS item_type, NULL AS doc_no, NULL AS doc_date,CASE WHEN i.total_amount > 0 THEN '应收' ELSE '收款' END,-- remaining_amount(本币) - remaining_amount(外币) * 新汇率。发票开了,钱没收到,就是应收。逻辑和客户对账一致,方向相反:应付为贷方,付款为借方。外币应收应付,月末按新汇率重新折算,差额计入汇兑损益。应付是采购到付款的闭环。发票来了,钱没付,就是应付。

2026-05-13 09:54:35 526

原创 ERP销售模块设计:从报价到收款

- 未设信用额度,不限制。-- 超额10%以内,警告。-- 超额10%以上,阻断。order_id BIGINT, -- 转为销售订单后关联。ar_invoice_id BIGINT, -- 关联应收发票。每层覆盖上层的条件不同:客户价按客户分类,促销价按时间段,协议价按合同。价格层级:标准价 → 客户价 → 促销价 → 协议价 → 手工价。-- 更新订单明细出货数量。-- 更新报价单状态。-- 更新出库单状态。

2026-05-13 09:50:04 536

原创 ERP二次开发:从需求到交付

优点:风险低,升级不受影响。缺点:只能存储数据,不能改变业务逻辑。在标准流程的特定节点插入自定义逻辑。优点:不修改源码,升级兼容。缺点:需要了解插件接口,调试困难。优点:解耦,易于测试。缺点:需要额外的接口层,复杂度增加。优点:性能好,逻辑集中。缺点:数据库耦合,难以版本控制。在标准表上增加字段,不影响原有逻辑。方案:开发报表平台,支持拖拽配置、自定义数据源。方案:开发审批引擎,支持条件分支、会签、加签。自定义对象要有统一前缀,避免和标准对象冲突。方案:开发移动端API,对接第三方移动平台。

2026-05-12 09:47:53 565

原创 ERP生产模块设计:从BOM到完工

run_time DECIMAL(10,2), -- 单件加工时间(小时)setup_time DECIMAL(10,2), -- 准备时间(小时)wait_time DECIMAL(10,2), -- 等待时间(小时)move_time DECIMAL(10,2), -- 移动时间(小时)base_quantity DECIMAL(18,6) DEFAULT 1,-- 成品基数。不同企业分摊方法不同。

2026-05-12 09:47:43 745

原创 ERP采购模块设计:从请购到入库

采购订单和入库单是多对多关系:一张采购订单可以分多次入库,一次入库也可以对应多张采购订单。生产部门提了采购需求,采购部门下了单,货什么时候到、到没到齐,都要能查到。suggested_supplier_id BIGINT, -- 建议供应商。need_date DATE, -- 需求日期。采购模块的典型流程:请购 → 审批 → 询价 → 下单 → 到货 → 入库 → 开票 → 付款。-- 更新订单明细的已入库数量。-- 更新入库单状态。

2026-05-11 14:36:49 524

原创 ERP销售模块数据库设计:从报价到收款

开票后credit_used增加,收款后减少。total_cost DECIMAL(18,2) DEFAULT 0, -- 销售成本。total_amount DECIMAL(18,2) DEFAULT 0, -- 销售金额。total_cost DECIMAL(18,2), -- 成本金额。total_amount DECIMAL(18,2), -- 销售金额。price_list_id BIGINT, -- 价格表。

2026-05-11 14:32:46 500

原创 ERP报表性能优化实战

status只有三五个值,选择性很低,单独建索引效果有限,customer_id有几万个不同值,选择性高,适合建索引。log_queries_not_using_indexes会记录没用索引的查询。报表查询慢,是ERP系统最常见的问题之一,一个复杂报表跑三五分钟,用户等得想砸电脑。索引字段顺序:等值条件在前,范围条件在后,排序字段在末尾。Using index表示走了覆盖索引,查询效率大幅提升。复杂报表不要实时计算。定期Review慢查询日志,持续优化高频查询。如果查询的所有字段都在索引中,不需要回表。

2026-05-09 09:33:23 433

原创 ERP权限体系设计:从功能到数据

功能权限控制能不能操作,数据权限控制能操作哪些数据,比如销售经理可以看所有销售订单,销售员只能看自己的订单,这就是数据权限。所有角色都用同一套数据权限规则,销售看客户、采购看供应商、财务看凭证,三种场景用同一套逻辑,最后谁都不满意。正确做法:超管账号严格管控,日常运维使用普通账号,权限不够时临时申请,用完即收回。开发方便,给超级管理员所有权限,结果运维人员也用超管账号,出了问题查不到责任人。正确做法:权限变更记录审计日志,谁、在什么时候、给谁、加了什么权限,全部可追溯。这个结构够用,但不够完善。

2026-05-09 09:32:25 530

原创 ERP库存模块数据库设计:从入到出全链路

如果A调B时先锁A后锁B,B调A时先锁B后锁A,可能会产生死锁,统一按warehouse_id从小到大排序后再加锁。allocated_qty DECIMAL(18,6) DEFAULT 0, -- 已分配未出库数量。secondary_quantity DECIMAL(18,6), -- 辅助单位数量。after_quantity DECIMAL(18,6), -- 变更后数量。system_quantity DECIMAL(18,6), -- 系统数量。

2026-05-08 10:23:39 1142

原创 ERP数据库设计规范:财务模块实战

source_module和source_id:业务系统生成的凭证必须记录来源,否则业务单据和凭证之间的联查就会断裂。月末结账后,历史期间的凭证要锁定,禁止修改。allow_post_before_date字段可以精确控制制单的时间权限,比简单的”已结账/未结账”两态更灵活。accounting_period VARCHAR(6) NOT NULL, -- 会计期间,格式:YYYYMM。account_code VARCHAR(20) NOT NULL, -- 科目编码,冗余存储加速查询。

2026-05-07 10:30:01 599

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除