Java SDK
在构建里加一个 jar,调用即可。不需要另外常驻的代理或服务。
当前可用的接入方式
还没提供的,就不写成已提供。在路线图上的,就标成路线图。
在构建里加一个 jar,调用即可。不需要另外常驻的代理或服务。
一个可执行 jar,从命令行或批处理里运行,能直接挂进现有的流水线。
在内网里也没有限制。与文档相关的信息不会外泄。
把它内嵌进贵司已有的解决方案,形式可以自由选。条件逐案商定。
基于 HTTP 的 XBRL API 计划于 2026 年下半年提供。
MirrorMere 不露面。
Java SDK
拿回来的不是一串错误代码。每一条都写明:在文档的哪个位置、违反了哪一款、因此手上拿着报送的人该去看什么。不管是 Dimensions 还是 Inline XBRL 抓到的,形态都一样,可以直接摆到经办人面前。
ValidationOutcome outcome = validator.validate(report);
for (ValidationFinding f : outcome.errors()) {
f.code(); // what went wrong
f.specRef(); // the clause it breaks
f.location(); // where in the document
}
调用一次,复核要用的东西就都在里面了:哪里、为什么、改什么。
CLI 与批处理
validatectsdoctor隔离网络
财务和审计部门常常在与互联网隔离的网络里办公。那些要从网上取校验依据的引擎,到这里就走不动了。更麻烦的是另一种:少校验了却一声不吭地放行。MirrorMere 根本不向外连。
如果您已经在用开源工具
市面上有免费的开源 XBRL 校验工具,其中也有和我们一样拿到 Validating Processor 认证的。若只是偶尔查一份报送,用它们就够了。但要把校验放进产品去卖,还需要另外三样东西。
MirrorMere 是为「进到产品里」而做的 Pure Java 库:往构建里放一个文件,在自己的代码里直接调用。不用另外守着一个进程,也不用维护一座桥。
规范改版时,跟上是我们的义务,不用您干等。卡住的时候,问题直接送到写引擎的人手上。
MirrorMere 在把 XBRL 搬过来的本体之上做推理,所以结论会同时带着:在哪、违反哪一条、该改什么——而且是手上拿着报送的人能直接照做的话。
也不必非要二选一。两边都跑、互相对照,同样是稳妥的做法——两个各自独立的实现给出同一个结论,这份一致本身就是证据。
对标准的承诺
这是装一次就要用上好几年的东西。所以规范一改,跟上是我们的事;没有重新通过全部标准测试之前,什么都不发布。您有问题,直接找到写引擎的人。
每次发版前都必须先跑通全部标准测试。哪怕弄坏一项,那次改动也到不了贵司。
规范改版时,只动对应的那个模块。您依赖的其余部分不动。
每个错误是什么意思、依据哪一条,都集中在一处,而不是散落在代码各处。规范一变,只有一个地方要改,改得快,也不容易漏。
到处找「为什么」的时间没有了。
先联系我们
您在做什么、卡在哪儿,说给我们听,我们陪您一起解。MirrorMere 的价值不在那个文件,而在这里。
习惯用邮件的话,直接写信给我们也可以。 manager@codebplat.co.kr