惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
罗磊的独立博客
小众软件
小众软件
T
Tailwind CSS Blog
宝玉的分享
宝玉的分享
博客园_首页
N
Netflix TechBlog - Medium
B
Blog
Recent Announcements
Recent Announcements
Y
Y Combinator Blog
Blog — PlanetScale
Blog — PlanetScale
L
LangChain Blog
F
Fortinet All Blogs
The GitHub Blog
The GitHub Blog
Stack Overflow Blog
Stack Overflow Blog
C
Check Point Blog
Last Week in AI
Last Week in AI
Jina AI
Jina AI
V
V2EX
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 叶小钗
博客园 - 【当耐特】

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
对接外采系统实战-以用友入账为例
亚亚的半亩田 · 2024-10-21 · via 人人都是产品经理

通过系统自动对接,可以实现数据实时同步,增加安全性和一致性,提高工作效率。这篇文章,作者就以用友为例,给大家分享了静态、动态数据对接两种方式,供各位参考。

在众多公司内部流程的系统化信息化,会存在以下几种的内部系统实现方式:

  1. 全部业务外采一个系统。这种方式适用于业务相对不复杂、流程较为简洁且标准化的公司。企业无需投入大量的开发资源,可快速部署并投入使用一个集成度较高的系统来满足基本的业务需求。
  2. 区分CRM、财务、人力采购不同的系统。或者CRM等一部分自建,专业领域如财务系统采购三方。是比较普遍的情况,特别是针对公司规模较大,业务比较复杂的公司。如果涉及到不同系统的对接,特别是内部系统与外部采购第三方系统的对接上,就会存在对接的产品方案和相关问题,即本文提到的跨系统数据同步
  3. 全部系统采取自建。适用于大公司,有雄厚的底蕴,或信息保密度高的公司。

在对接数据上,一般分为静态数据对接、动态数据对接。以下方案会区分两种类型进行说明。在需求描述上,一般会区分为数据规则、业务规则、同步规则等等。

一、系统自动对接的价值

  • 提高工作效率:由人工在系统间的数据同步转变为系统间自动化同步,简化人力工作。员工不再需要耗费大量时间和精力在繁琐、重复的数据导出、处理、导入上。提高工作效率,降低维护成本
  • 保持数据一致性:系统对接,会减少不同系统之间数据线下传输带来的数据遗漏,保持各系统之间数据的一致性。无论是在销售、财务还是人力资源等各个业务模块,都能实时获取准确统一的数据,为企业的决策提供可靠依据。
  • 加强数据安全性:会计数据会涉及到很多如客户信息、收入信息等敏感数据,系统间对接可以加强安全性。系统间的对接可以通过加密传输、权限管理等多种安全措施,加强数据的安全性。
  • 实时数据同步:人工操作不可避免地会存在时间差,而系统间可以实时、T+1、月度等灵活的设置同步时间,企业可以根据不同的业务场景和数据时效性要求,选择合适的同步时间,确保数据能够在需要的时候及时更新,

二、静态数据对接

2.1 逻辑说明

静态数据的同步是将一个相关稳定的、不随时间频繁变化的数据同步到另外一个系统的过程。比如客户数据、供应商数据等。

(1)数据特点

  • 变化频率低:一旦创建或更新之后,较长时间内保持稳定
  • 同步频率低:同步的频率相对较低,可以按天、或按周按月进行数据同步

(2)同步方式

一般采取全量同步+定期触发的同步方式:

  • 全量同步:全量数据进行同步。适用于数据量较小、同步频率较低的场景。优点是简单易行,不需要考虑数据的变化情况。缺点是在数据量较大时,同步时间较长,可能会影响系统的性能。
  • 定期触发,设置每天定时的同步任务,系统自动执行,将源数据同步到目标系统中。

2.2 凭证入账-静态数据

以凭证对接对接用友为例,在入账过程中,需要客户名称、供应商名称等作为凭证数据的辅助项、或者其他数据使用。具体对接包括客户名称、供应商名称、订单编号、流水编号、员工信息等。

(1)业务规则需求描述

  1. 确认需要同步的数据范围
  2. 不同系统之间的数据格式不同,所以可能存在数据转换和清洗
  3. 针对数据字段的对应关系,要求在不同系统重结构和定义保持一致。并且根据不同的对应关系给出不同的具体需求描述

(2)同步规则

  1. 定时同步,可以采取增量每天凌晨定时同步,在月度入账时再判断数据缺失时再同步一次
  2. 定时同步,定时全量数据同步

(3)错误数据处理和恢复

在数据同步过程中可能会存在错误的情况,如网络中断、数据传输失败。针对不同的情况,需要有重试机制,预警告知等方式。

三、动态数据对接

3.1 逻辑说明

动态数据一般是指随着时间不断变化的数据,比如订单数据、库存数据、凭证数据等。

(1)数据特点

  • 变化频率高:这些数据在业务进行过程中不断发生变化,会有新数据的产生或现有数据被更新
  • 数据一致性要求高:动态数据的同步对一致性要求比较高

(2)同步方式

一般采取增量同步+事件触发的同步方式

  • 增量同步:动态数据一般采取增量数据同步,是只同步自上次同步以来发生变化的数据。适用于数据量较大、同步频率较高的场景。同步时间短,对系统性能的影响较小。但是实现起来相对复杂。
  • 事件触发:可以通过事件触发的方式进行动态数据同步。针对比较复杂的业务或者数据情况,需要有人工验证之后再进行同步,同步的方式对应的也是增量同步或全量同步。

3.2 凭证入账-动态数据

3.2.1 需求前置说明

在上篇文章《0-1搭建账务自动化集成系统》https://www.woshipm.com/pd/6127328.html 提到,集成系统会在T+1更新凭证数据,下一步,就是财务会将凭证数据对接至用友进行入账操作。

与静态数据的同步不同,因为月度的凭证数据量较大,所以数据同步一次需要几个小时以上,所以凭证数据的同步会比较复杂,接下来进行说明。

3.2.2 同步凭证数据步骤

在系统搭建之初,正式入账会存在一定的风险,特别是可能存在还有一部分人工入账的情况,所以在凭证数据对接至用友未完全验证之前,需要先进行测试验收。财务验收有两个步骤:

  • 第一个步骤:财务针对凭证数据验证(账务自动化集成系统中生成的)
  • 第二个步骤:针对同步到用友的凭证数据进行验证,为什么需要再次验证呢,因为摘要、会计科目、辅助项(客户名称、订单编号等)都会使用同步至用友或在用友维护的静态数据组成。比如A系统的会计科目与B系统的会计科目需完全保持一致,如果不一致,则凭证有问题,其他的都类似。

所以针对第二个步骤的验证,在系统对接的前期,需要加入到同步过程中,所以同步凭证的步骤包括:

  1. 凭证数据生成:账务自动化集成系统已生成凭证数据,按业务码逐个入账
  2. 对接用友测试:在测试月份,按集成数据对接用友,若成功则显示凭证号
  3. 验收正式入账:财务已在测试月份验证完成,正式月份入账,返回凭证号

所以同步用友的需求状态分为以下5个步骤:

(1)凭证数据生成

依据凭证数据产生的异常提醒+人工框定数据范围,系统自动产出凭证数据:

(2)对接用友测试

因为数据量比较大,在上线前期几个月会先对接到未来月份(暂时不用的某个月)进行同步数据验证。财务同学可以针对有问题的凭证进行原因排查。同步至用友测试月份,状态为【对接用友测试中】。

  1. 在对接用友测试过程中,会存在同步至用友的报错情况,所以需要有预警或重试机制。比如,如果是通过用友过程中发现客商名称有缺,则自动触发客商名称同步之后,再进行凭证同步的重试;或者其他的看板或消息,便于财务或研发同学及时介入进行处理。
  2. 进行中数量限制:未避免同步问题,同步进行中的数据限制为1个,完成1个之后再进入下一个入账操作。

(3)对接正式入账

在测试无误之后,操作对接正式月份进行入账,同样会有对接时长。同步至用友正式月份后,状态为【正式入账已完成】。

3.2.3 上线前配套工作

(1)操作手册与培训。凭证数据的生成和对接至用友功能使用上,会有各种的问题,产研在交付之前,需要罗列各种可能遇到的报错类型,并告知对应的解决方案。在上线的前两个月,产研需与财务协同进行使用跟进。

(2)上线前新旧方案切换。上线前由财务人工入账,上线后很大可能是一部分由系统自动入账,加一部分人工入账,所以在切换过程中,需要选择合适的时间合适的方案进行切换,以确保数据的连续性、一致性、全面性。

(3)实时监控和调整。针对静态数据和动态数据的同步,都需要建立实时监控,观察数据的变化情况或问题,能及时调整系统参数和优化同步策略。

(4)应急预警机制。入账是每月财务重点工作,在功能上线同时,需要制定应急预案,以防在上线出现意外情况,确保能够在最短时间解决问题。

本文由 @亚亚的半亩产品田 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自 Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务