1.开天aPaaS API key验证的连接器创建文章链接：https://bbs.huaweicloud.com/blogs/384386文章描述：详细描述了开天aPaaS API key验证的连接器创建相关流程等。2.华夏天信携手华为云开天aPaaS，打造安全、高效、节能的主煤流运输系统文章链接：https://bbs.huaweicloud.com/blogs/384312文章描述：基于开天aPaaS集成工作台，主煤流运输系统如何实现多源异构数据融合、皮带物料和人员违章的智能感知，以及皮带的智能控制。灵活架构、高效集成、快速开发等。3.【Datawhale动手学数据分析笔记】第一章 数据加载及探索性数据分析文章链接：https://bbs.huaweicloud.com/blogs/384298文章描述：详细描述了数据加载及探索性数据分析相关知识点。4.软考信息安全工程师必会--3000+字文章浅析DES加密算法文章链接：https://bbs.huaweicloud.com/blogs/384139文章描述：详细描述了DES全称为Data Encryption Standard，即数据加密标准，是一种使用密钥加密的块算法，1977年被美国联邦政府的国家标准局确定为联邦资料处理标准（FIPS），并授权在非密级政府通信中使用，随后该算法在国际上广泛流传开来。需要注意的是，在某些文献中，作为算法的DES称为数据加密算法（Data Encryption Algorithm,DEA），已与作为标准的DES区分开来相关知识点等。5.分布式版本控制工具Git官网概述、下载安装和代码托管中心文章链接：https://bbs.huaweicloud.com/blogs/384115文章描述：Git是个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种项目。Git 易于学习，占用面积小，性能极快。 它具有廉价的本地库，方便的暂存区域和多个工作流分支等特性。其性能优于Subversion、CVS、Perforce和ClearCase等版木控制工具。本文中详细了相关知识点。6.华为开发者大赛获奖作品丨提升80%上云集成效率，TA是如何做到的？文章链接：https://bbs.huaweicloud.com/blogs/383875文章描述:   详细描述了基于华为云开天aPaaS，提升80%上云集成效率，降低50%集成成本，TA是如何做到的。7.【区块链Go】基础语法文章链接：https://bbs.huaweicloud.com/blogs/383804文章描述: 详细描述了【区块链Go】基础语法相关知识点。以上就是部分11月应用构建文章的汇总。

有没有人已经到手了的？我这边申通的都不推送信息了，不知道什么情况。

2022年CCF中国软件大会（CCF ChinaSoft 2022）将于2022年11月25-27日在线上举行。预期将有林惠民、陈左宁、邬江兴、何积丰、梅宏、吕建、柴洪峰、廖湘科、王怀民、郑纬民、蒋昌俊、王自力等10余位院士莅临。本次大会主题是“聚焦产教研用协同创新，提升关键软件供给能力”，包括学术、工业、教育等论坛活动40余场，期待您的参与！cid:link_2论坛巡礼本文特别介绍将于11月25日举办的【编译器与编程语言】论坛。论坛名称：编译器与编程语言时间: 2022年11月25日下午13:30-17:00论坛简介：随着摩尔定律趋于平缓，硬件多样化发展，给编程语言和编译器带来了黄金时代。通用算力持续发展遇到瓶颈挑战，异构芯片和并行计算是发展趋势。融合应用的创新驱动着基础软件发生变革，使能统一的多样性计算生态。本论坛将讨论如下问题:1) 系统编程语言技术创新路在何方，是并行，安全还是其他？2) 外部封锁，工艺受限形势下，编译器如何协同硬件打造技术竞争力？3) 新兴编译技术，比如量子，AI等技术如何在工业界落地？4) 集成开发环境如何适应新的趋势，提升开发体验？5) 如何加强国内编程语言和编译器等核心基础软件的研究，打造开发者生态?直播链接大会微官网：https://zb.51fxkj.com/live/page/C72AC44DFE170E8EBEAF5755EB4ADF68?topicid=894507314&v=638045575064743719B站直播：cid:link_3日程安排更多信息请 点击 查看

11月2日-10月15日期间在码豆商城兑换的礼品现已出库转入快递公司，物流信息预计将于7个工作日内更新，届时请关注申通公众号/菜鸟裹裹/支付宝-我的快递等物流平台查看详细物流信息。如兑换后超过30个工作日仍未收到快递请尽快联系小助手微信devcloud1。 *受疫情影响暂停发货的订单将暂存物流网点，待物流恢复正常后陆续发货。================这个日期是后面的10月15日，是写错了，本来是11月15日？还是说 这个期间是10月15日-11月2日 之间？

10月13日15:00后陆续补货 9月29日已补货， 兑换后20个工作日内安排发货， 感谢大家的支持，还请耐心等待。 更多礼品请登陆华为云码豆会员中心查看。 *受疫情影响暂停发货的订单将暂存物流网点，待物流恢复正常后陆续发货。

近年，电子签章的应用让政府机关、企业内部高频使用的证明材料逐步实现“网上申办、短信送达”，免去重复提交材料的麻烦，实现“零跑腿、零纸张、线上办、自主办”，助力政府机关、街道社区、高校、医院、慈善平台以及工程项目组织等实现线上秒开证明。“证明文件”一般为格式文件，盖章工作较为机械化，且签署量大，特别是大型集团企业或者政务服务机关，常用的人事证明及业务证明日签署量多达上千份。繁琐的线下盖章程序让原本简单的办事场景逐渐复杂化，开证明成了“老大难”。契约锁电子签章系统支持集成各类政务服务系统、OA办公系统、专项业务软件以微信公众号等，帮助政府机关及企业打造面向群众和员工的“业务证明电子签章平台”，多种签署功能支撑，解决政务服务及企业管理中的“开证明”难题，让证明不再难开：（各类业务证明电子签方案）“电子模板”帮助一键起草证明：格式化的证明文件直接套用契约锁电子模板一键生成，工作人员无需反复起草，统一格式、规范内容。“批量盖章”提升证明签署效率：对于签署频率高、数量多的证明文件，每日定时统一查看待签任务，一次完成批量盖章，减轻人工机械化盖章压力。“自动盖章”助力减轻签署压力：常办证明支持审批后系统自动盖章，省去人工拖拽盖章的步骤，进一步简化证明签署程序。“指定签署位置”让证明签署更智能：契约锁支持提前指定签署位置，精准定位盖章，让证明签署更规范。支持证明文件“在线验真伪”：在线签署的电子证明文件可以随时在线查验印章真伪情况，有效防伪造。常见证明场景中的电子签应用：在企业证明类型：收入证明｜离职证明｜在职证明｜公积金证明｜复工证明等线下办员工必须找HR咨询办理，不仅HR工作量大，有时员工在项目上、在外地，也只能为了一份证明回公司盖章，时间协调不好的话，一天也盖不了章，员工常常体验不佳，耽误办事进度。电子签契约锁支持集成OA、HRM等管理系统，打造员工电子证明服务平台，此类人事证明只需打开手机APP提交申请流程，几分钟即可下载PDF电子文件，省去咨询人事、来回跑腿、催进度的烦恼。（集成OA、HRM系统，员工自主申请开证明）在高校证明类型：学籍证明｜学历证明｜学位证明｜在读证明｜毕业证明｜职称证明｜奖学金证明｜荣誉证书证明｜论文引用证明等线下办学生必须前往校务处找老师签字、盖章，不仅手续多、周期长、体验差，学校每天还要投入大量人工盖章、开证明，纸张、打印成本高，校园服务亟待转型。电子签契约锁连接校园网上办事大厅及打印设备，打造面向全校的自主用印平台，老师和学生通过手机、校园自助设备即可申办证明、自动盖章、按需下载。（自助设备便捷办理证明）在街道社区证明类型：党组织关系接收证明｜婚育情况证明｜独生子女证明｜租住证明｜房产证明｜产权人关系证明｜居住证明｜户口迁入/迁出证明｜家庭关系类证明｜贫困证明、经济情况证明等线下办居民只能亲自前往街道社区开证明，有时负责人外出不在，常常来来回回跑了五六趟才能办完，基层服务跟不上。电子签契约锁集成基层服务平台、微信公众号，为群众提供电子证明自助办理渠道。3-5分钟即可在线盖章，高效办事。（基层组织居住证明文件签署）在医院证明类型：诊断证明｜病休证明｜健康证明｜核酸证明｜出院证明等线下办医院门诊每天都要面对庞大的人流量，门诊检测、诊疗等证明文件咨询、办理量大，内部制作和盖章成本高，门诊医生每天需要投入大量时间为患者开证明。电子签契约锁集成HIS信息系统，连接微信公众号及自助打印设备，患者手机端自主申办、医生HIS系统电子签名、自动添加医院印章、患者自助下载打印，高效服务。（病假单在线盖章）在政府机关证明类型：房产备案证明｜不动产登记信息查询证明｜不动产登记证明｜公积金缴存证明｜住房贷款结清证明｜社保缴纳证明｜婚姻登记证明｜新生儿出生证明等线下办居民只能到政府机关营业厅当面办理，不仅往返、跑腿麻烦，还要提交大量纸质材料，从排队咨询、预约、办理到办结，全程至少需要5-10天时间，耗时费力。不仅群众办事难、政府机关也将面临盖章效率低、办事材料归档难等问题。电子签契约锁电子签章系统支持对接政府机关服务平台及微信公众号。居民登录微信公众号或办事服务平台即可申办，机关内同步审批、在线盖章，提升房产交易网签及备案、不动产登记、公积金缴存及新生儿登记等证明材料签署效率。↓ 例如：1）不动产查询证明：契约锁集成不动产登记系统、连接不动产登记便民小程序，居民打开手机、认证身份，即可在线申办、查询证明开具进度、在线下载使用，原本5-9天的办事周期缩短至2天内即可办结。2）公积金缴存证明：契约锁对接“住房公积金综合服务平台及APP应用”，为外部缴存单位及个人常办业务提供电子签名、电子盖章支撑。缴存企业及职工只需登录手机端，即可自主生成、下载或者打印带有缴存地住房公积金管理中心业务专用章的证明文件，无需前往缴存地柜台，实现全程网上办。3）出生医学证明：契约锁支持对接计生部门业务平台，连接微信公众号，为新生儿医学证明申请提供线上申办、电子盖章渠道，无需跑腿、高效下载PDF电子出生证明。在慈善平台证明类型：电子捐赠证明线下办慈善组织需要向每项捐赠开具纸质证明凭证，捐赠者遍布各地，签发纸质证明不仅给平台带来了庞大的用纸、快递成本。还容易破损，保存难。电子签契约锁对接慈善平台，捐赠者在线认证身份、填写捐赠信息后，即可自动获取一份加盖机构电子印章的PDF版捐赠证明。可验真，防诈捐。（电子捐赠证明）在工程项目组织证明类型：财务拒收证明。施工方开具发票给到项目部，但是基于各种原因，发票每个月都会有3-5个不符合要求，项目部需要开具《拒收证明》，盖企业公章（原件），跟发票一块儿返还给施工方、重新开票。线下办施工方开拒收证明得由项目部准备纸质申请单、回总部或者让人捎带过去盖章，3-5天左右盖章文件才能带回、寄送给施工方。整个签署周期较长，用纸、车船费用成本高。电子签契约锁电子签章对接工程公司总部OA办公系统，偏远项目部可以通过OA系统在线申请签署拒收证明。总部3-5分钟审批盖章、按需下载。无需多地来回周转，提升项目部用印效率。总结近年，电子签章在政府机关及企业数字化建设中发挥了重要作用，通过安全、便捷、无纸化的电子签署服务，帮助打通政务服务及企业管理全程数字化的最后一公里。通过简化盖章工作，让办证、开证明线上几分钟内即可办结，让企业管理、办事、居民服务更加便捷。

【问题来源】公司内部实践学习【问题简要】was配置助手配置was数据源失败【问题类别】   AICC【AICC解决方案版本】【必填】    【AICC版本：AICC 8.15.1】    【UAP版本：UAP9600 V100R005C00SPC028】    【CTI版本：ICDV300R008C23SPC010】【问题现象描述】配置was数据源失败【错误截图】

从前面几篇文章，我们了解了 NMT 的基础知识以及 NMT 追踪区域分析的相关内容，本篇文章将为大家介绍一下使用 NMT 协助排查内存问题的案例。6.使用 NMT 协助排查内存问题案例我们在搞清楚 NMT 追踪的 JVM 各部分的内存分配之后，就可以比较轻松的协助排查定位内存问题或者调整合适的参数。可以在 JVM 运行时使用 jcmd VM.native_memory baseline 创建基线，经过一段时间的运行后再使用 jcmd VM.native_memory summary.diff/detail.diff 命令，就可以很直观地观察出这段时间 JVM 进程使用的内存一共增长了多少，各部分使用的内存分别增长了多少，可以很方便的将问题定位到某一具体的区域。比如我们看到 MetaSpace 的内存增长异常，可以结合 MAT 等工具查看是否类加载器数量异常、是否类重复加载、reflect 的 inflation 参数设置是否合理；如果 Symbol 内存增长异常，可以查看项目 String.intern 是否使用正常；如果 Thread 使用内存过多，考虑是否可以适当调整线程堆栈大小等等。案例一：虚高的 VIRT 内存我们还记得前文（NMT 内存 & OS 内存概念差异性章节）中使用 top 命令查看启动的 JVM 进程，仔细观察会发现一个比较虚高的 VIRT 内存（10.7g），我们使用 NMT 追踪的 Total: reserved 才 2813709KB（2.7g），这多出来的这么多虚拟内存是从何而来呢？top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27420 douyiwa+ 20 0 10.7g 697560 17596 S 100.0 0.3 0:18.79 java Native Memory Tracking: Total: reserved=2813077KB, committed=1496981KB复制使用 pmap -X 观察内存情况:27420: java -Xmx1G -Xms1G -XX:+UseG1GC -XX:MaxMetaspaceSize=256M -XX:MaxDirectMemorySize=256M -XX:ReservedCodeCacheSize=256M -XX:NativeMemoryTracking=detail -jar nmtTest.jar Address Perm Offset Device Inode Size Rss Pss Referenced Anonymous LazyFree ShmemPmdMapped Shared_Hugetlb Private_Hugetlb Swap SwapPss Locked Mapping c0000000 rw-p 00000000 00:00 0 1049088 637236 637236 637236 637236 0 0 0 0 0 0 0 100080000 ---p 00000000 00:00 0 1048064 0 0 0 0 0 0 0 0 0 0 0 aaaaea835000 r-xp 00000000 fd:02 45613083 4 4 4 4 0 0 0 0 0 0 0 0 java aaaaea854000 r--p 0000f000 fd:02 45613083 4 4 4 4 4 0 0 0 0 0 0 0 java aaaaea855000 rw-p 00010000 fd:02 45613083 4 4 4 4 4 0 0 0 0 0 0 0 java aaab071af000 rw-p 00000000 00:00 0 304 108 108 108 108 0 0 0 0 0 0 0 [heap] fffd60000000 rw-p 00000000 00:00 0 132 4 4 4 4 0 0 0 0 0 0 0 fffd60021000 ---p 00000000 00:00 0 65404 0 0 0 0 0 0 0 0 0 0 0 fffd68000000 rw-p 00000000 00:00 0 132 8 8 8 8 0 0 0 0 0 0 0 fffd68021000 ---p 00000000 00:00 0 65404 0 0 0 0 0 0 0 0 0 0 0 fffd6c000000 rw-p 00000000 00:00 0 132 4 4 4 4 0 0 0 0 0 0 0 fffd6c021000 ---p 00000000 00:00 0 65404 0 0 0 0 0 0 0 0 0 0 0 fffd70000000 rw-p 00000000 00:00 0 132 40 40 40 40 0 0 0 0 0 0 0 fffd70021000 ---p 00000000 00:00 0 65404 0 0 0 0 0 ......复制可以发现多了很多 65404 KB 的内存块（大约 120 个），使用 /proc//smaps 观察内存地址：...... fffd60021000-fffd64000000 ---p 00000000 00:00 0 Size: 65404 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 0 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB VmFlags: mr mw me nr ......复制对照 NMT 的情况，我们发现如 fffd60021000-fffd64000000 这种 65404 KB 的内存是并没有被 NMT 追踪到的。这是因为在 JVM 进程中，除了 JVM 进程自己 mmap 的内存（如 Java Heap，和用户进程空间的 Heap 并不是一个概念）外，JVM 还直接使用了类库的函数来分配一些数据，如使用 Glibc 的 malloc/free (也是通过 brk/mmap 的方式)：既然 JVM 使用了 Glibc 的 malloc/free，就不得不提及 malloc 的机制，早期版本的 malloc 只有一个 arena（分配区），每次分配时都要对分配区加锁，分配完成之后再释放，这就导致了多线程的情况下竞争比较激烈。所以 malloc 改动了其分配机制，甚至有了 arena per-thread 的模式，即如果在一个线程中首次调用 malloc，则创建一个新的 arena，而不是去查看前面的锁是否会发生竞争，对于一定数量的线程可以避免竞争在自己的 arena 上工作。arena 的数量限制在 32 位系统上是 2 * CPU 核心数，64 位系统上是 8 * CPU 核心数，当然我们也可以使用 MALLOC_ARENA_MAX （Linux 环境变量，详情可以查看 mallopt(3)[1]）来控制。查看发现运行 JVM 进程的环境 CPU 信息（物理 CPU 核数）：Core(s) per socket: 64 。我们给当前环境设置 MALLOC_ARENA_MAX=2，重启 JVM 进程，查看使用情况：top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 36319 douyiwa+ 20 0 3108340 690872 17828 S 100.0 0.3 0:07.61 java复制虚高的 VIRT 内存已经降下来了，继续查看 pmap/smaps 会发现众多的 65404 KB 的内存空间也消失了（120 * 65404 KB = 7848480 KB 正好对应了 10.7g - 3108340 KB 的内存，即 VIRT 降低的内存）。为什么我们的 JVM 进程会使用如此多的 arena 呢？因为我们在启动 JVM 进程的时候，并没有手动去设置一些进程的数目，如：CICompilerCount（编译线程数）、ConcGCThreads/ParallelGCThreads（并发 GC 线程数）、G1ConcRefinementThreads（G1 Refine 线程数）等等。这些参数大多数根据当前机器的 CPU 核数去计算默认值，使用 jinfo -flags 查看机器参数发现：-XX:CICompilerCount=18 -XX:ConcGCThreads=11 -XX:G1ConcRefinementThreads=43复制这些线程数目都是比较大的，我们也可以不修改 MALLOC_ARENA_MAX 的数量，而通过参数减小线程的数量来减少 arena 的数量。Glibc 的 malloc 有时会出现碎片问题，可以使用 jemalloc/tcmalloc 等替代 Glibc。案例二：堆外内存的排查有时候我们会发现，Java 堆、MetaSpace 等区域是比较正常的，但是 JVM 进程整体的内存却在不停的增长，此时我们就可以使用 NMT 的 baseline & diff 功能来观察究竟是哪块区域内存一直增长。比如在一次案例中发现：Native Memory Tracking: Total: reserved=8149334KB +1535794KB, committed=6999194KB +1590490KB ...... - Internal (reserved=1723321KB +1472458KB, committed=1723321KB +1472458KB) (malloc=1723289KB +1472458KB #109094 +47573) (mmap: reserved=32KB, committed=32KB) ...... [0x00007fceb806607a] Unsafe_AllocateMemory+0x17a [0x00007fcea1d24e68] (malloc=1485579KB type=Internal +1455929KB #2511 +2277) ......复制我们可以确认内存 1590490KB 的增长，基本上都是由 Internal 的 Unsafe_AllocateMemory 所分配的，此时可以优先考虑 NIO 中 ByteBuffer.allocateDirect / DirectByteBuffer / FileChannel.map 等使用方式是不是出现了泄漏，可以使用 MAT 查看 DirectByteBuffer 对象的数量是否异常，并可以使用 -XX:MaxDirectMemorySize 来限制 Direct 的大小。设置 -XX:MaxDirectMemorySize 之后，进程异常的内存增长停止，但是 GC 频率变高，查看 GC 日志发现：.887+0800: 238210.127: [Full GC (System.gc()) 1175M->255M(3878),0.8370418 secs]。FullGC 的频率大大增加，并且基本上都是由 System.gc() 显式调用引起的（HotSpot中的System.gc()为 FulGC），查看 DirectByteBuffer 相关逻辑：# DirectByteBuffer.java DirectByteBuffer(int cap) { // package-private ...... Bits.reserveMemory(size, cap); long base = 0; try { base = unsafe.allocateMemory(size); } catch (OutOfMemoryError x) { Bits.unreserveMemory(size, cap); throw x; } unsafe.setMemory(base, size, (byte) 0); if (pa && (base % ps != 0)) { // Round up to page boundary address = base + ps - (base & (ps - 1)); } else { address = base; } cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); att = null; } # Bits.java static void reserveMemory(long size, int cap) { ...... System.gc(); ...... }复制DirectByteBuffer 在 unsafe.allocateMemory(size) 之前会先去做一个 Bits.reserveMemory(size, cap) 的操作，Bits.reserveMemory 会显式的调用 System.gc() 来尝试回收内存，看到这里基本可以确认为 DirectByteBuffer 的问题，排查业务代码，果然发现一处 ByteBufferStream 使用了 ByteBuffer.allocateDirect 的方式而流一直未关闭释放内存，修正后内存增长与 GC 频率皆恢复正常。参考https://man7.org/linux/man-pages/man3/mallopt.3.html往期推荐Native Memory Tracking 详解（1）:基础介绍Native Memory Tracking 详解（2）:追踪区域分析(一)Native Memory Tracking 详解（3）:追踪区域分析(二)欢迎加入Compiler SIG交流群与大家共同交流学习编译技术相关内容，扫码添加小助手微信邀请你进入Compiler SIG交流群。

报销是组织常见的业务，涉及到每个员工。在传统的报销过程中，如何提升发票归集效率，提升员工填单、报销体验，提高领导审核、财务复核的智能化和自动化水平？随着国家政策推进，电子发票的范围不断扩大，发票加速推进全领域、全环节、全要素电子化，其中发票报销是实现全程数字化的关键一环。泛微新一代全程数字化费控管理软件-齐业成，为组织提供一站式的报销解决方案，协助组织实现业务数据关联，智能合规检测；使报销更便捷、审批更方便、财务更轻松！（齐业成报销应用示意图）齐业成移动报销亮点介绍一、发票收集-自动归集、查验01自动化发票采集，全票种自动识别1）自动获取途径：支付宝/微信、邮箱（票箱、个人邮箱、企业邮箱）、云盘、短信、链接、发票助手小程序等；2）手动获取方式：（发票收集方式）02全票种智能合规检验齐业成既支持与税端直联，实现对增值税发票的自动真伪查验、价税分离；也支持通过自定义发票合规指标，如发票验真、去重、连号、发票敏感字、黑白名单自定义设置等。灵活满足组织内控合规要求，发票基于内控合规规则进行有效查验跟控制，从源头杜绝虚假发票报销，避免组织合规风险。（发票合规检验）二、报销发起-快捷创建01便捷创建报销单1）自动创建报销a、根据事前申请（例如出差、业务招待、员工活动等）自动匹配发票自动生成报销，报销单内容根据事前事由及发票明细自动带出；b、固定报销（例如每月话费报销、油补报销、餐补报销）结合申请标准，自动根据标准创建报销，报销单内容自动带出；c、无法匹配到事前流程的发票，根据发票跟费用类型对应关系自动生成报销单，员工只需补充报销事由即可。2）语音发起报销通过智能小e助手，通过说一句话的形式，系统根据说的内容自动创建报销单。（首页-语音交互-表单生成）3）发票一键生成报销支持自定义报销字段匹配规则，台账批量勾选发票，由系统自动解析票面内容识别发票信息，并自动匹配报销费用科目，一键生成报销明细信息，减少人为录入，提升填报效率与单据合规性。（一键发起报销）4）事前申请一键创建报销通过批量勾选待报销事前流程，系统根据规则自动创建报销单，报销事由、日期、相关客户、项目、发票、金额等信息自动带出；除了自动创建报销带出报销内容信息外，因为事前流程领导已审核，报销流程还可以设置免审规则，符合规则的流程领导节点自动处理，缩短审批周期，减轻领导审批工作量。（事前申请一键带出报销信息）02智能带出报销数据1）费用科目智能匹配费用科目信息支持根据所关联的事前流程结合发票信息，自动智能匹配带出，无需人为录入修改，提升填报效率与单据合规性。（费用科目智能匹配）2）行程单智能匹配对于网约车平台的打车费用报销，报销时只需要选择费用发票后，可以自动关联带出行程单，无需手动匹配发票和行程单关系。（行程单智能匹配）三、报销高效审批-多维度数据统计及检01多维度数据统计与合规检验，辅助决策支持审批时系统自动进行多维度预算及费用的检查与管控，通过助手实时预警，防范费用超支与超标的风险，方便领导审批。预先设定业务合规规则，例如是否关联事先申请，是否关联相关合同、发票是否合规等等，系统自动进行合规检查，识别潜在风险，领导审核更高效、更智能，更合规，提升审批效率。（个人、部门费用执行情况）（智能合规检查）02RPA机器人让审批自动化（自定义审批规则）（审批监控，风险提示）四、财务智能审核-智能票审，一键打印01财务智能票审，审核电子、纸质发票财务审核节点通过票审页面将流程中的发票信息统一展现，直观的看到发票风险情况，发票详细信息等等。针对含纸质发票的流程，通过高拍仪/扫描仪批量识别发票信息，通过线下发票与线上报销信息进行自动匹配并快速识别发票风险。（财务智能票审）02报销票据一键打印财务节点可以通过一键打印功能，将报销单、发票、行程单、其他报销凭证等信息一键批量打印。（票据一键打印）五、报销入账电子归档-全程数字化在财务节点，无论是线上电子票据文件，还是纸质发票文件，统一通过影像文件形成电子化数据文件，按照电子会计档案管理规范，实现报销入账归档。价值总结收集发票环节：多种发票收集渠道，自动识别、验真与风险校验；员工发起环节：提供多种便捷式填报方式，减轻员工填报工作量；领导审批环节：审批自动化，智能助手数据支撑，协助高效审批；财务审核环节：智能票审，一键打印归档，减少审批打印工作量；归档环节：线上线下发票与凭证在线自动归档，统一数字化管理。

上次看到专属码豆区有个电动牙刷，就发帖说想让小助手上到普通区，没想到真给上了，谢谢小助手

鼠标点击下拉选项无法选中

中国冶金地质总局山东局始建于1953年，隶属于中国冶金地质总局，是从事固体矿产资源勘查、开发、研究与服务的事业单位，为国家矿产资源开发和山东经济社会发展做出了突出贡献。随着工程管理数字化转型的不断推进，中国冶金地质总局山东局为在全局施工企业推行经营机制改革，化小核算单元，全面实行目标成本责任制。此次，携手泛微数字化运营平台，建设全生命周期的数字化工程项目管理应用，在一个平台上集中统一化管理，推动组织“工作制度化、人员职业化、目标精细化、手段信息化”的全方面提升。泛微通过低代码构建平台+流程，为中国冶金地质总局山东局建立了从项目立项前的招投标管理、到项目立项审批，覆盖项目执行过程中投标保证金申请、项目立项、履约保证金申请、合同登记、预算编制、项目产值登记、收款开票、款项领取、项目费用支出、完工结算、兑现、考核等全生命周期管理体系。（应用架构）中国冶金总局山东局工程项目管理平台一、数字化的投标管理流程化管控1、投标项目信息登记业务人员通过投标项目信息登记流程，维护投标项目信息，经过流程审批登记入库。2、投标保证金申请和收回业务人员投标登记后，通过申请流程发起投标保证金申请，通过落地标准化、规范化的审批流程，通过编制投标预算及标前评审申请该项目的投标保证金，上报本部。项目经理也可以通过流程反馈保证金去向（已收回、未收回、转履约）以及中标情况，确保资金申请全程规范性。3、招标项目公告发布项目管理人员可选择中标项目发布公告，流程审批后平台将相关文档推送在门户中。二、数字化的项目管理直观获取管理要点1、项目立项项目立项为整个业务产出必有的前序流程，在立项时需要编制项目成本预算，提供预算编制模板，登记人可根据项目情况编制预算表并上传。2、项目数字化卡片项目卡片实时的数据统计面板，让项目的进度一目了然，当延误发生时，及时处理，轻松掌控公司每个项目的运行情况。可视化展示项目基本信息、项目合同、项目产值结算信息、项目资金收支情况，项目成本与预算情况、到款情况等内容，直观获取项目管理要点。3、项目数字化台账项目信息是项目实施过程的信息聚合中心，形成以项目为主线的数据中心，方便给项目人员直观的展示项目综合信息。（项目台账）三、数字化项目预算管理可控、可灵活变更1、预算校验立项后，该项目一切成本费用的发生都根据预算控制校验。超出预算，无法进行成本费用的发起。（预算校验）2、预算执行进度实际成本和预算对比，计算生成该项目各类费用的预算执行进度，直观的展现出预算执行情况，提醒项目人员控制预算或进行预算变更。（预算执行）3、预算变更预算发生变更，需要关联项目进行变更，选择项目后将自动带出该项目的基本信息及原预算。同时，需要再次上传预算编制表，说明变更原因，严格把控预算变更。流程驱动审批后更新项目新预算。并且生成变更台账，方便管理层查看单位项目预算的变更情况及次数。四、数字化项目收支管理成本实时归集，控制超支1、项目到款认领款项到账后，财务人员导入到款池，项目成员通过到款池直接认领，自动创建到款认领单，关联相关项目及开票信息。（到款确认）流程审批通过后，更新项目资金收入，发票应收账款余额等。2、项目成本确认由各分公司会计批量导入项目成本，项目人员进行成本确认，触发审批流程。审批结束后，系统自动更新各项目对应的成本。3、供应商付款支出供应商付款作为工程项目常见的支出，需要进行有效的管控。系统以供应商合同记录相关供应商信息。通过累计完成产值、历史已收票、已支付金额记录应付账款。最终通过项目所编制预算，控制项目支出，扣减可用预算。通过本次付款与累计付款计算获取项目已支出金额，并更新记录入工程项目卡片中。项目所发生的人工费、税金、技术服务费等其他费用支出同样通过流程驱动审核确认写入项目成本当中。五、数字化的项目结算每月登记，结算考核一体化每月对项目进行产值登记，项目完工后的结算，以及后续的考核及兑现。项目人员通过项目产值登记完成项目现场施工进度、甲方确认产值累计等，并记录是否需要回款，预计回款金额及预计回款时间并及时提醒回款责任人及时跟进项目开票、收款情况。并且可查看过去每月登记情况，避免重复登记。六、多维度分析报表让数据有效统计及分析问题工程行业数据量多、散，需要集中展现每个项目的实时数据。泛微通过低代码构建多数据台帐，针对单位、部门、时间等不同维度查看所有项目各类收支情况，以项目全周期以及资金收支为维度可进行多方面信息查询，提高协同办公效率，并且助力工程项目报表移动化。（移动报表）价值总结泛微通过流程+低代码的方式，为中国冶金地质总局山东局搭建了以项目为主线，覆盖项目全生命周期执行过程平台，形成项目、合同、成本预算、资金收支、产值结算数据可视化管理体系。助力中国冶金地质总局山东局提升项目协作效率，明确审批权责，落地有效管控：规范过程：项目作业上传相关依据，及时掌握项目现场情况，规范项目收支审批过程。事前申请：问题事前反馈，预算事前申请，根据项目的登记情况，实时更新项目相关数据，知晓最新项目进度及成本。监管到位：上级单位可浏览全局项目情况，以及项目管理各模块数据汇总情况，及时管控。

我参加了2022华为开发者大赛 · 云应用创新赛道，这全国总决赛都参加完了，为什么初赛入围的码豆为什么不能领？有没有大佬知道的？麻烦了！！！

继续等待华为AI音箱2e

随着组织发展、规模扩张，门店与员工人数不断增加，商超行业面临着效率的变革。其中采购对整体效率有着重大影响。连锁超市需要为多个城市、多个门店提供采购及管理服务，从需求、寻源、采购到配送，每个环节的效率应该如何提升？>>>连锁超市采购管理痛点：• 采购种类多，数量大，价格差异大，非标性强，产地分散；• 食品等物料采购需要对供应商资质及原材料品质进行管控；• 采购相关工作量大，每月有大量的合同、对账，开票工作；• 如何释放现金流压力，了解实时财务状况，规划现金流？• 采购过程中物料、采购、合同、付款信息如何统一协同？泛微京桥通全程数字化采购管理系统，协助连锁商超，灵活对接其他第三方系统，建立集中化的采购平台，实现一站式集中采购，实现采购业务资源共享业务协同，构建面向上下游一体化的数字化采购平台。（连锁商超采购流程架构）请购-订购-合同-付款的全过程采购管理一、供应商全业务协同供应商引入连锁商超行业供应商数量多，为了提升效率，通过统一发送邀请邮件或外部网站自助注册的方式，快速将供应商引入，并且能自助维护供应商信息、自动进行供应商数字身份认证，自动识别供应商资质风险。采购人员也可以通过企业微信添加供应商，将供应商联系方式及时同步到OA的供应商管理库，通过企业微信就能随时查看供应商信息。（微信注册-企业微信添加联系方式）供应商信息管理供应商申请流程审批完成后自动进入供应商库，供应商各类信息统一维护查看，并且可对供应商的证件证照统一管理，统一归档存证，所有使用记录可查可追溯。通过与第三方征信平台打通，将供应商的征信实时进行反馈，当供应商出现法律诉讼、信息变更、经营异常等情况时，系统可及时提醒采购人员，及早做出相应的对策。二、物料管理新品需求申请连锁商超经常会新增采购物料，以满足超市产品的更新。泛微协助连锁商超通过流程提交新品物料打样申请，供应商提供样品打样确认后可以进入物料库。（新品需求申请）物料库新品需求打样并经审批完成后，生成物料信息；物料信息可以与门店物料信息进行匹配，生成物料报表。三、寻源管理采购需求按照各业务单元不同权限，分别展现历史交易，采购需求等关注信息；采购专员定期下发采购需求，各部门采购专员负责填报，层层审批和汇总；采购需求汇总成池，支持按照物料类型进行合并和拆分。通过流程发起请购申请，根据业务需求判断类型；请购申请单允许关联多个物料、多个厂商，并根据物料的不同，可进行不同的审批判断。（请购申请）报名业务处理及保证金凭证上传供应商可以在线进行报名，上传投标保证金凭证、预审资料上传和报价信息等；待报名时间截止后，采购方可在线确认报名供应商信息并对保证金缴纳情况确认。预审业务采购员可查看提交资格预审的供应商列表，下载供应商附件，并对供应商进行预审审批。（预审业务）询价过程当询价报价后，采购方可根据需要发起多轮询价，供应商在报价台账中可进行多轮报价操作，且每次询价结果会记录在系统中。询报价比价当询价报价后，采购方可对各单位报价结果进行对比，可通过比价助手提供比价数据汇总、物料报价排名、数据看板等信息，辅助比价评标。在线议价系统支持评审阶段发起议价，也可以选择在核价阶段发起议价，或者两个阶段都能发起议价。供应商可填写还价单价和还价理由进行供应商报价还价。四、订购、合同管理订购申请完成请购后，业务部门按照不同需求分别提交订购申请，并且关联请购单，对订购物料的进行管控，订购详情自动带出。统一台账管理，并提供多维度查询功能。实时准确传递交期、进度、质量、技术要求等关键信息。送货管理整合物流信息，实现企业和供应商之间的物流信息协同，建立需求拉动、进度实时追踪；支持配置化实现各种收货模式，合理管控收货流程。质量管理质量管理确保采购物料经过质检标准；对于不合格的物料，进行记录，注明质检结果、数量、处理方案等信息和供应商可在第一时间进行确认。（质量管理）扣费管理对于不合格、数量短缺的物料，系统支持进行扣费管理，生成扣费单，明确扣费原因、项目、事由、金额等情况。供应商可在第一时间收到扣费信息并进行反馈，同意是否进行扣费。验收申请完成订购交货物验收后，需提交验收申请单；验收单针对订购单一对一完成物料验收.。合同申请在新供应商或者新品打样阶段，需要与物料供应厂商签订采购合同。若是已签署框架合同的采购，无需提交采购合同申请流程，直接申请请购、订购、验收流程即可。五、采购付款管理对账及发票管理订单收货执行后，双方均可提出对账申请，最终系统自动生成对账单，并进行线上签章确认。结合OCR影像识别，发票验真，快速开票，实现电子发票管理，并在线进行发票审批。采购付款管理在对账完成后，采购人员收到供应商开来的发票，系统可参照采购订单、收货单、发票进项三单匹配，生成采购付款申请，对接财务系统进行付款。（采购付款管理）采购付款申请必须关联订购单；一个付款申请单允许关联同一个厂商对应的多个订购单；付款金额按照订购单对应的验收金额进行管控。采购统计采购综合统计表，支持按多纬度进行查询；关联采购过程涉及的请购单、订购单、验收单、付款单、供应商、付款状态等信息；每个过程管理台账，均可实现与其他过程的数据关联穿透。（采购统计）六、报表管理根据门店管理要求，泛微协助连锁商超，构建了各类物料数据报表。补货建议报表：通过物料信息、门店每日出入库信息对系统数据进行统计分析根据物料库中设置的安全水位线以及近7日平均出库货进行预测分析系统出具补货建议报表。需要补货时，自动触发邮件及提醒流程至每个分管的物料负责人。出入库明细报表：统计门店每天出入库明细信息。待摊明细报表：统计每个门店、每个月需要分摊的物料及费用明细信息。总结泛微协助连锁商超，梳理统一采购业务条线的流程，实现了采购业务全过程管理，加强了采购过程及费用管控，降低了企业经营风险，为企业的业务快速发展和管理复制，打下了坚实的基础。