支持与故障排除
在这里查找常见问题的答案；当文档无法解决您的问题时，也能知道该去哪里求助。
从这里开始
故障排除
故障排除内容放在出问题的那个地方，而不是单独成章。每个 applet 的参考页面都有一个 Troubleshooting（故障排除） 部分，列出该 applet 实际会产生的错误以及处理办法——请从问题出现时您正在使用的那个 applet 开始查起。
向人求助
请在 BigLedger-Support/public 提交一个 issue——这是 BigLedger 公开的咨询跟踪平台。任何人都可以在上面发帖，您能看到别人已经问过的问题，答案也会一直保留，留给下一个遇到同样问题的人。请说明您当时在哪个 applet 中、您预期会发生什么，以及实际发生了什么。由于任何人都能阅读这个平台，请不要在帖子里写您的租户代码或您自己的业务记录： 关于产品本身的问题适合发在那里，关于您自己租户的问题则不适合。
您的 BigLedger 联系人——也就是为您公司完成上线的那个人或合作伙伴——是处理一切与您租户相关事项的最快途径：权限、电子发票授权、applet 注册或数据问题。他们能看到您的配置，文档看不到。如果您的组织里没人知道联系人是谁，可以在跟踪平台上询问联系人——这个问题不涉及您自己的任何细节，而得到的答复会给您一条私下沟通的渠道，用来处理那些涉及细节的问题。
当只有支持团队能解决时——以及具体要发送什么
本 wiki 中有不少页面的解决办法以联系支持、询问您的 BigLedger 联系人或询问您的管理员结尾。只有当页面说明了为什么您无法自己完成以及消息里该写什么时，这样的结尾才算诚实。所以这里统一说明一次，每个指向本页的页面都以此为准。
先确认这件事是不是其实可以自己做
最常见的请求是*“我的租户上有个后台任务没有运行”*——电子发票的定时处理从不触发、补货运行从不发生、通知从不发出。定时计划本身就是您自己租户的 cron 表中的一行，由 Scheduler applet 写入。 如果您的 applet 列表中有 Scheduler，并且您拥有创建计划的权限，就可以自己添加这个定时：Scheduler → + → 点击 Scheduler Code → 在 Select Processor 选择器中选出处理器 → 设置 cron 表达式 → Status 设为 ACTIVE。这个选择器也是产品中唯一能让您看到**您的租户实际拥有哪些作业处理器（job processor）**的界面——在向任何人提问之前，值得先了解这一点。
在按 + 之前，先查看 Scheduler 列表。 如果该处理器已经有一行，那么问题在于它为什么没有触发——从它的 Last Run Date 开始查——而不是要不要再加一行。产品中没有任何机制阻止您为同一个处理器再创建一行；如果您这样做了，两行都会触发。
如果您的菜单里没有 Scheduler，或者按 + 被拒绝，那不是需要向我们提出的请求。 applet 的使用权来自 Applet Store，权限来自Settings → Permission Set / Role Permission——两者都在您自己的租户内，都由您自己的管理员授予。请先问他们，再来问我们——这一区别在本页最后一节说明。
不要就此止步，也不要根据本页去猜测其余的部分。 cron 表达式按 UNIX 五字段格式解析；新计划的首次触发时间从您创建它的那一刻起向后推算；需要属性的任务在该行的 Json 标签页中填写属性；而计划 Edit 界面上的 Run 会立即触发一次，让您今天就知道结果，而不必等到明天。所有这些内容，以及如何区分“从未触发”的计划和“触发了但失败”的计划，都在 Scheduler applet 页面上，包括如何先安全地试一试。需要哪个处理器，请看那件没有发生的事情所在的页面——Peppol 指南写明了 Peppol 的定时处理，电子发票 applet 页面写明了电子发票相关的处理器。
您在那里做不到的，是让一个处理器首次出现在那个选择器中。所以，如实的分工是：
| 您想做的事 | 谁能做 |
|---|---|
| 为已在 Select Processor 选择器中的处理器设置计划、修改频率，或立即运行一次 | 您，在 Scheduler applet 中 |
| 查看您的租户到底有哪些处理器 | 您——Select Processor 选择器 |
| 让一个不在选择器中的处理器对您的租户可用 | 我们。产品中没有任何界面能做到 |
| 启动读取 cron 表的“起搏器”本身——症状是所有计划任务都没有运行过，任何处理器都没有。提问前先在一个计划上按 Run：如果 Run 有效，但从来没有任何任务自行触发，那么坏掉的是 cron 这条路径，把这句话发给我们即可 | 我们 |
| 安装一个不在 Applet Store 中的 applet | 我们 |
| 写入任何界面都没有提供的凭证、令牌或预置参考数据行 | 我们 |
| 修复已经生成的单据 | 我们 |
要发送什么
以我们结尾的那几行需要不同的信息，因为在我们这边要创建或修改的东西各不相同。发错了信息，就要多来回一次。
哪个“我们”？ 凡是涉及您自己租户的事项，都找您的 BigLedger 联系人——本页上的每一项请求都属于这一类。公开跟踪平台用于询问产品本身的问题；由于任何人都能阅读，请不要在帖子里透露您的租户和您的数据。
不在您选择器中的处理器，或只有我们能创建的计划。 一行 cron 记录由三个字段组成，缺一不可，所以三个都要写明，然后再写您的租户：
- 处理器代码，与您看到的写法完全一致——不要写成“那个 Peppol 定时处理”。如果您没有代码，就说明是哪个界面没有正常工作，由回复来提供代码；
- 频率——多久运行一次，以及是否需要在某个特定时间（在每月 7 日前几天运行的合并处理，与“每小时一次”是完全不同的请求）；
- 该任务需要的属性（如果您知道）：哪家公司和哪个分行，因为有些任务会从属性中读取公司，缺少时会中止整次运行；
- 另外单独写明您的租户代码，以及任务运行后您期望看到什么，这样回复时才能告诉您它是否已运行。租户代码不是您的公司代码，也不是分行代码——这是三个不同的代码，发错了就要多来回一次。如果您不确定哪个是哪个，就直接说明，并写上您的公司名称；回复方可以查到对应的租户。
不在 Applet Store 中的 applet。 写明 applet 名称、需要它的登录账号或团队，以及您想用它做什么——有少数 applet 的注册记录是有意停用的，答案是另一个 applet，这样的回复比安装更快。
凭证、令牌或预置数据行。 说明是哪一项、哪家公司，以及——对于同时有测试环境和正式环境的项目，例如 LHDN 中介配置——哪个环境。配置放错了环境，看起来与从未配置过完全一样。
修复已经生成的单据。 这一项中，细节决定了能否修复：
- 单据编号，或其导出清单——一份清单永远胜过一段描述；
- 您预期会发生什么，以及实际发生了什么，按这个顺序写；
- 单据是何时最终确认（finalise）的，以及下游是否已经使用了它——已报送 LHDN、已在银行对账中匹配、已包含在已提交的申报中。已报送的单据不是被更正，而是被取代，这会改变答案；
- 您已经尝试过什么。 重新最终确认、撤回为草稿和作废都会留下各自的痕迹，需要先把这些解开。
不要发送什么
不要粘贴密码、访问密钥或 API 令牌。这里没有人需要它们，而一旦密钥出现在工单中，就必须将其吊销。如果单据编号就足够，就不要发送包含真实客户记录的电子表格。
如果答案是“询问您的管理员”，我们指的不是我们
有些页面会让您去找您自己的管理员——即您的组织中拥有所有者（owner）或管理员（admin）权限的人。那是另一条途径，而且更快：权限、会隐藏某个标签页或按钮的 applet 设置，以及按用户设置的默认值，都是在您的租户内部、由已经拥有相应权限的人修改的。如果某个页面让您去问管理员，却没有说明他们应该打开哪个界面，那是页面的问题——告诉我们，我们会修正它。