I have vouchers which has to be digitally signed by the higher official abc, xyz.
I know that digital signature has to be added in the PDF file (report output), but not sure how, also that certain methods of PDF has to be called from Axapta but don't know what those methods are and how they can be called.
Kindly assist me on how to approach.
An electronic signature by itself is not the same as a digital signature. An electronic signature is simply a substitute for a handwritten signature, while a digital signature provides additional security measures.
Digital signature
I would recommend that the PDF is generated by AX as normal, then digitally sign it after the higher official has read and approved the document. The signature has to be applied after document generation, because it contains a hash of its content.
The signature could be done by third party software.
Start by reading Adobe's page on the matter.
Electronic signature
AX 2012 has some functionality, start here.
AX 2009, see Dilip's blog, also remember to enable the configuration key.
Microsoft Dynamics AX 2009 does not provide a complete system for the capture and processing of electronic signatures. But it does provide a kernel event and an editable event method. These can be the foundation for an electronic signature subsystem to be developed by partners
The AX 2009 SP1 What's new goes:
Microsoft Dynamics AX 2009 SP1 provides a system for capturing and for processing electronic signatures. The system provides several built-in signatures, such as Bill of Material Approval.
You can enable the built-in signatures by using the Electronic signature requirements form. This form also enables the administrator to define new signatures for tables or fields. Defining new signatures requires careful planning to avoid excessive security which could block proper access to tables.
For more information about using built-in signatures or defining new signatures, see "Electronic signature requirements (form)" in System and Application Setup Help. In the SP1 edition of the Help, see "Generic electronic signatures".
Related
I've been using VS Code for a year or so now. I have no idea how VS Code Extension security is handled.
I'm alarmed by things like this:
Markdown Preview Enhanced (927K+ downloads)
Markdown Preview Enhanced (fork that points to the original repo) (2k+ downloads)
Some questions I have are:
What does Microsoft do to ensure Extensions we install are safe?
Are they scanning the Extensions for known vulns?
Is VS Code safe to use in an Enterprise Environment?
How can I tell?
Why are duplicate extension names allowed!
There are security and marketing implications by Microsoft allowing "package-squatting".
Does anyone have insights to share regarding VS Code Extension Security?
Hm. Unfortunately, the link to "extension marketplace terms" that #jonrsharpe provided does not include the word "extension". If you extrapolate VS Code Extensions to be covered by the Azure Marketplace terms (as alluded to in the text), then you get this little tidbit:
https://azure.microsoft.com/en-us/support/legal/marketplace-terms/
Publisher Privacy Policies. Publishers are responsible for providing
privacy statements that describe their privacy practices with respect
to Customer Data collected by their Offerings or any customer
information that they receive from Microsoft. Unless indicated
otherwise in connection with a Marketplace Offering published by
Microsoft, Microsoft’s privacy, security, and data location and data
retention policies will not apply to any Marketplace Offering or to
Publishers’ use of any Customer Data or other customer information.
In short "...Microsoft's privacy, security...policies will not apply to any..." VS Code Extensions OR to "...Publishers' use of any Customer Data or other customer information."
Microsoft does NOT handle VS Code Extension Security.
We have a custom solution made up of several screens that are packaged as a customization package. We'd like to be able to lock that down so that users need to purchase a license key to use these screens. I don't want to re-invent the wheel, so I'm wondering if there are standard examples (if this has been done before) on how to integrate this with Acumatica's license system.
It is not possible to integrate with the Acumatica licensing system. We implemented our own licensing and required the license when the Acumatica license has been applied. This is indicated by PXLicenseHelper.License.Licensed
I should point out I did spend a good amount of time on this very question before we implemented licensing for our product.
Am working for a Medical devices company and we are trying to use Static code analysis tools for our development.Can somebody help us in validating whether Visual Studio 2012 Code Analysis feature is complaint to FDA or not?
I believe TFS can be validated for FDA Compliance for Static Code Analysis and other requirements depending on your QSIA Intended Use. As mentioned in OP's comment the key is validating how you are using a tool, not whether it is validated "out of the box". I believe you must validate that you have configured and use static code analysis in a way that is compliant. Just having a tool doesn't make its output automatically compliant (unless there is a "FDA-compliant" setting that cannot be disabled :-)).
Food and Drug Administration (FDA) Compliance with Visual Studio 2010 (MSDN whitepaper by Northwest Cadence, June 2011)
has an extensive walkthrough of TFS features mapped to FDA compliance and FDA document "General Principles of Software Validation". Static code analysis is specifically mentioned. Here is the relevant excerpt:
Static Code Analysis
The static code analysis in Visual Studio 2010 has several hundred rules that check code for potential code errors in several areas, which include design, naming, reliability and security. These rules can be combined into rule sets that allow only a specific subset of the rules to be run, highlighting potential problems. These range from the “Minimum Recommended Rules," which focus on the most critical problems in your code, including potential security holes, application crashes, and other important logic and design errors, to the “All Rules” set. which contains every available rule. It’s very easy to configure a custom rule set to focus your code analysis specifically toward your needs.
There may be other references that are (or will be) relevant. Try following search keywords: TFS FDA (or better yet use +TFS +FDA to force major search engines to have both terms). +VS +FDA might return other relevant results especially if you are looking specifically for code analysis rather than overall compliance for eSignature and other Part 11 requirements.
Please vote if you found this helpful. Thanks! -Zephan
VS2012 is not compliant to FDA
Looking for solution to be able to allow our CRM users to sign online documents on our site , is there opensource solution for this ?
basically we will be signing the documents on behalf of the customer for the supplier but of course customer himself will be signing online, so here we will use one certificate to sign for different customers... timestamp and other features required to be the legal,
and if there is open source solution or one of small cost product would cover Annex1 and Annex2 all the required points
http://www.berr.gov.uk/files/file49952.pdf
we found this but would this work on Linux servers http://www.signfiles.com/digital-certificates/ and ItextPDF but would any of this be ok for legal side of things ?
Thnx
You might want to check out a service like DocuSign which already has integrations with major CRMs. Your main issue here is proving that it actually happened and that it's legally binding. The best way to do this is not to have an open source solution that you control, but to rely on a trusted 3rd party.
Full disclosure: I work for DocuSign.
Let's assume that you've created a SharePoint solution - a WebPart, a feature for a List Template, whatever - that you are planning to sell as a product.
How would you go about handling licensing of your solution?
I'm looking for some input in at least the following areas:
Code-wise:
1.1. Where do you keep the license itself? as a file somewhere? (then what happens in farms?) as a property in the property bag of the farm?
1.2. Do you implement "home-calling" - where your solution validate the license every now and then against your company's servers?
1.3. Any other best practice in this area will be welcome...
Business wise: How do you license - per user? per server? per instance (in case of WebParts or List Templates)?
Thanks.
I could tell you what we do:
We have a separate farm solution that handles trial/registration support for all our products
The license is eventually stored in the farm property bag (you have to support multiple servers)
We have a page to enter license key under the central admin solution's page
We license by front-end, you can know the number of front-end in the farm in code.
All products have a product name and the license key is a one-way encryption containing the product name. the trial support solution handles key validation.
1.1 You have to put in in the documentation and in the distribution files.
1.2 I would not do that for a sharepoint web part.
1.3 Invest in layout, documentation, support... Not just in the product itself.
Nobody will be able to answer that without knowing detailed information about your product, your market, your competitors, the alternatives, etc. Consider this book if you are serious about pricing.