I wrote a C# application to send a MS Word document to signers. I added multiple text tabs, signature tabs, social security tabs, etc. The application reads a local MS Word document, creates the envelope, places the tabs, and sends the document.
Everything was working fine until today when all the tabs are misplaced in the document sent by DocuSign. When reviewing the original document and the final document sent by DocuSign, I noticed that the top spaces/margins of the pages aren't being respected by DocuSign which causes all the fields to be misplaced. There were no changes to the original document. Does anyone have any idea of what could be the issue?
Solved the issue. I reset the top margins on all pages and the problem is gone. Basically, I changed the margins and put them back to where I needed them.
Related
I have a custom list tracking idea submissions (think virtual suggestion box) where I am attempting to customize the DispForm.aspx so that users will not see fields that are not directly relevant to viewing the submission.
I am making a copy of the original DispForm.aspx and renaming to i_DispForm_mod.aspx and then changing the settings of the list to use this as the display form.
Problem is, once I modify the display form settings, it takes over the whole ball of wax. I can no longer access EditForm.aspx. Clicking on "Edit" gets you the display form.
Creating the URL to the edit page manually takes you to the display page. Creating a new item works as normal.
For some reason, SP is deciding to redirect all requests for EditForm.aspx to the display form. Properties for the list supporting files are set to all the appropriate pages - but SP is ignoring that in favor of serving up the display form. WTF?
I have no idea how to fix this. This is my second go-round with this after abandoning the first list created when I first got this behaviour.
Oh and just to add additional fun, the behaviour persists after restoring to original DispForm.aspx and resetting list supporting file properties appropriately.
Absent solutions I may have to mark DispForm.aspx as radioactive, do not touch and abandon my design as unattainable.
I cannot find anything similar being documented anywhere on the web.
I need create documents from my software to api integration but I would like of mark the place of signature for client.
Its possible?
Sure, easy-peasy. When creating the DocuSign envelope, include a sign here tab with the create call. And use anchor text to tell DocuSign where the signature request should appear.
Here is the recipe. And here is example software that you can run on Heroku for free.
Note: in order to run the recipe on Heroku, you'll need a free developer account on DocuSign, plus a free integration key.
When creating envelopes in the DocuSign system there are generally three different methods for placing signature and other tabs.
Absolute (or fixed) positioning.
Relative positioning (aka Anchor Tags or Auto-Place).
PDF Form fields.
(1): With absolute positioning you can set the (x,y) coordinates of where you want to place tabs through your documents. You can set that manually by dragging and dropping through the DocuSign Website, or you can set those locations through the API. See Larry's API Recipes links.
(2): The anchor tagging (aka Auto-place) feature places tabs in your documents based on the actual document content itself. For instance, you can place a signature tab anywhere the text "Please Sign Here" is found in your document(s). However please note that it will place a signature tab for each and every instance of that string it finds, not just the first.
(3): The third option for placing tabs only work with non-flattened PDF files. If you have a PDF with form fields in it, DocuSign can read those fields and locations and place tabs there. This is easy and powerful, but of course only works with PDF files.
Learn more about all these option at the DocuSign Developer Center.
What I've found is that it will place a signature tab for every document in an envelope, even if the other documents are using a different server template.
My responsive email template is showing a distinct problem when it comes to testing for Gmail viewed on iOS. Where the two parts are meant to stack are in fact two tables nested inside another one. When I view the code in my email (on desktop with narrowed browser window), after sending the test, I see that gmail has un-nested these tables. The result on the appearance is not what i am looking for. In the screenshot the highlighted table is supposed to be inside the table above with the 100% width.
I have been using this template for the past few months and it was never doing this, have there been developments with gmail?
We have a system that creates pre-filled PDF contracts that we then need to send to the customer for signature and also allow the customer to update fields that may contain erroneous information.
I have reviewed the API extensively and understand that I can use text tabs placed on the document to allow customer to edit those fields. However this approach is not replacing the value already on the PDF, rather writing over it. See attached screenshot of sample document: DocuSign Overwrite text field
What is the alternative or any tips on how to get around this issue will be highly appreciated.
Here is one workaround or option but I hope there is a better way
1) Instead of using the templating engine that generates this PDF, move this burden to Docusign. We can then use the text tabs within Docusign to pre-populate fields and leave it editable.
When you send a PDF with form fields DocuSign can convert those PDF form fields into DocuSign data tabs which I believe is the workaround you've mentioned. This is definitely the easiest approach and should work.
You can do a quick manual test by uploading a document into the DocuSign console (ie login to your account through the website) and if you feed it a PDF with form fields the system will ask if you'd like to convert them to DocuSign tabs. To achieve this through the API you can use the transformPdfFields property in the document object.
We had a need for a document management solution and were hoping SharePoint 2007 would satisfy our needs. We felt our needs were relatively simple. We needed to manage versioning, have searching capabilities, and having an approval workflow.
SharePoint handled these three aspects great out of the box.
However, we also require that the footer on the Office 2007 (Word, Excel, and PowerPoint) documents reflect the document version, last person to modify, and last modification date. These things can be done with office automation, but we have yet to find a complete solution.
We first tried to do it on the checking-in and checked-in events and followed this path for a while, however, the complication we ran into was after we made the changes to the document we had to no way of preventing the save from updating the version number. This resulted in something similar to this:
Document checked-in – the document version should be v0.1 however it is v0.2 because we save the document after the footer is replaced. If we look in the document history we there are 2 separate versions v0.1 does not have the footer v0.2 has the footer but it says v0.1 as that is the version the document was when it was replaced.
This is an unacceptable solution for us as we want the process to be completely handled on the user side so they would have full control to revert back to a version where the footer would be incorrect and not contain the correct data. When we attempted to create a custom approval/check-in workflow we found that the same problem was present. The footer is necessary so that hard-copies can be traced back to their electronic counterpart.
Another solution that was proposed to us was to build plugins for office that would handle the replacement of the footer. This is inadequate for our needs as it requires a client side deployment of our plugins which is undesirable by our clients. What we are looking for is a clean solution to this problem.
Here is a blog post which seem to be exactly the solution of your problem.
Basically they create a custom field in the document library and use event receivers to keep the current version of the document in this field.
The "trick" is that on the client side this custom field shows up as a property of the document the value of which you can easily embed into the document's contents.
I'm not sure why changing the field won't increase the version of the document, but I guess it is because you're only changing metadata, not the actual document.
They do use a little VBA script which runs on the client side, but it doesn't require any client side deployment as it is downloaded with the document. However I'm not sure if any security settings changes on the client side may be needed to allow the script to run.
Does this information need to be in the footer? A lot of the information is available within the Office 2007 application. If you click on the round button in the upper left, and select "Server", you can view the version history, a lot of the other properties are available by clicking the round button and opening the "Prepare" menu, and selecting Properties.
If this information must be displayed in the document footer I would investigate creating a custom Information Management Policy. This may be a good place to start.