【发布时间】:2018-03-01 17:59:06
【问题描述】:
我们已经在生产中使用 DocuSign C# API 的代码已有一年多的时间了,其中包括一些成功地从某些收件人而不是其他收件人中排除文档的代码。现在,在一种新的信封类型上,我收到了上述错误,不知道为什么。下面是经过轻微编辑/匿名的 JSON 请求负载和带有错误的 DocuSign 响应(均使用 Fiddler 捕获)。
如您所见,有三个文档和两个签名者,两个签名者都获得文档 ID 1,一个签名者被排除在文档 ID 2 之外,另一个签名者被排除在文档 ID 3 之外。还有两个抄送收件人他们都是我们账户的内部员工。值得一提的是,帐户上的文档可见性设置是“必须签名才能查看,除非是发件人帐户的成员。”
这是发送到 DocuSign 以创建信封的 JSON 有效负载:
{
"documents": [
{
"documentId": "1",
"name": "Document1",
"fileExtension": "pdf",
"order": "1",
"documentBase64": "blahblahblah"
},
{
"documentId": "2",
"name": "Document2",
"fileExtension": "pdf",
"order": "2",
"documentBase64": "blahblahblah"
},
{
"documentId": "3",
"name": "Document2",
"fileExtension": "pdf",
"order": "3",
"documentBase64": "blahblahblah"
}
],
"recipients": {
"signers": [
{
"tabs": {
"signHereTabs": [
{
"name": "Joe Smith",
"tabLabel": "Signature1",
"scaleValue": "0.9",
"documentId": "1",
"recipientId": "1",
"anchorString": "Some anchor text",
"anchorXOffset": "4",
"anchorYOffset": "46",
"anchorMatchWholeWord": "true",
"tabId": "Signature1"
},
{
"name": "Joe Smith",
"tabLabel": "Signature2",
"documentId": "2",
"recipientId": "1",
"anchorString": "Some other anchor text",
"anchorXOffset": "4",
"anchorYOffset": "67",
"anchorMatchWholeWord": "true",
"tabId": "Signature2"
}
],
"dateSignedTabs": [
{
"tabLabel": "DateSigned1",
"documentId": "1",
"recipientId": "1",
"anchorString": "Some anchor text",
"anchorXOffset": "175",
"anchorYOffset": "38",
"anchorMatchWholeWord": "true",
"tabId": "DateSigned1"
}
],
"textTabs": []
},
"recipientSuppliesTabs": "false",
"excludedDocuments": [ "3" ],
"name": "Joe Smith",
"email": "joesmith@example.com",
"emailRecipientPostSigningURL": "https://www.foocorp.com/e-consent-complete/",
"recipientId": "1",
"customFields": [],
"routingOrder": "1",
"roleName": "Signer",
"emailNotification": {
"emailSubject": "Joe Smith has documents from Foo Corp",
"emailBody": "Blah blah blah"
}
},
{
"tabs": {
"signHereTabs": [
{
"name": "Bob Jones",
"tabLabel": "Signature1",
"scaleValue": "0.9",
"documentId": "1",
"recipientId": "2",
"anchorString": "Some anchor text",
"anchorXOffset": "277",
"anchorYOffset": "46",
"anchorMatchWholeWord": "true",
"tabId": "Signature1"
},
{
"name": "Bob Jones",
"tabLabel": "Signature3",
"documentId": "3",
"recipientId": "2",
"anchorString": "Some other anchor text",
"anchorXOffset": "4",
"anchorYOffset": "67",
"anchorMatchWholeWord": "true",
"tabId": "Signature3"
}
],
"dateSignedTabs": [
{
"tabLabel": "DateSigned1",
"documentId": "1",
"recipientId": "2",
"anchorString": "Some anchor text",
"anchorXOffset": "448",
"anchorYOffset": "38",
"anchorMatchWholeWord": "true",
"tabId": "DateSigned1"
}
],
"textTabs": []
},
"recipientSuppliesTabs": "false",
"excludedDocuments": [ "2" ],
"name": "Bob Jones",
"email": "bobjones@example.com",
"emailRecipientPostSigningURL": "https://www.foocorp.com/e-consent-complete/",
"recipientId": "2",
"customFields": [],
"routingOrder": "1",
"roleName": "Signer",
"emailNotification": {
"emailSubject": "Bob Jones has documents from Foo Corp",
"emailBody": "Blah blah blah"
}
}
],
"carbonCopies": [
{
"name": "Sue Employee",
"email": "sue@foocorp.com",
"emailRecipientPostSigningURL": "https://www.foocorp.com/e-consent-complete/",
"recipientId": "3",
"customFields": [],
"routingOrder": "1",
"roleName": "Internal",
"emailNotification": {
"emailSubject": "Joe Smith has documents from Foo Corp",
"emailBody": "Blah blah blah"
}
},
{
"name": "Sam Employee",
"email": "sam@foocorp.com",
"emailRecipientPostSigningURL": "https://www.foocorp.com/e-consent-complete/",
"recipientId": "4",
"customFields": [],
"routingOrder": "1",
"roleName": "Internal",
"emailNotification": {
"emailSubject": "Joe Smith has documents from Foo Corp",
"emailBody": "Blah blah blah"
}
}
],
"certifiedDeliveries": []
},
"status": "created",
"emailSubject": "Joe Smith has documents from Foo Corp",
"emailBlurb": "Blah blah blah",
"allowMarkup": "false",
"allowReassign": "false",
"recipientsLock": "true",
"emailSettings": {
"replyEmailAddressOverride": "sue@foocorp.com",
"replyEmailNameOverride": "Sue Employee"
}
}
这是 HTTP 响应:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Content-Length: 177
Content-Type: application/json; charset=utf-8
X-RateLimit-Reset: 1519927200
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 997
X-DocuSign-TraceToken: deadbeef-dead-beef-dead-beefdeadbeef
Date: Thu, 01 Mar 2018 17:25:01 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains
{
"errorCode": "CANNOT_EXCLUDE_DOCUMENT",
"message": "This document cannot be excluded for this recipient. Recipient: Joe Smith cannot be excluded from Document:"
}
任何方向表示赞赏。
已编辑以显示排除的文档都具有相同的名称,因为它对我来说是一个“逻辑名称”,例如,我将“W9”与文档上的自定义字段结合使用,然后路由到 doc 中的正确位置通过 Connect 调用返回时进行管理。如果我发送具有不同名称的文档 id 2 和 3,那么一切正常。但是排除是通过文档 ID 起作用的,而不是文档名称,那么这有什么关系呢?
编辑 #2:我能够向自己证明,文档名称是什么并不重要 - 无论它们是相同还是不同,我都会得到错误。
【问题讨论】:
-
奇怪,我尝试了你的 JSON 请求,它对我有用:{ "envelopeId": "aa66541c-1b65-4057-b97f-e0272d16cfcf", "uri": "/envelopes/aa66541c-1b65- 4057-b97f-e0272d16cfcf”、“statusDateTime”:“2018-03-01T19:39:44.1570000Z”、“状态”:“已创建”}
-
这很奇怪。我发现整个 API 设计得非常好(除了一小部分),这只是我第二次感到“惊讶”。我反对演示网站,因为它仍在测试中 - 你反对演示还是生产?
-
我尝试过演示环境。但如果你愿意,我可以试试生产版。我自己在所有交易中都使用此功能,但从未遇到过此问题。
-
@Frederic,好吗?我认为这不会改变你的结果,但我试图消除变量。我也一样,在同一个项目的另一个地方使用这个功能没有问题。今天我也会自己做更多的测试,看看我能不能弄清楚。这是一个奇怪的!
-
其实我才发现我没有生产账号。但是我的客户在生产中很好地使用了这个功能,并且实际上确认这样的 JSON 请求将在生产中工作。是您发送的确切消息吗?
标签: docusignapi