So we have a client that is wanting to replace all of their forms they use with digital versions where the data entered into them are stored in a centralized database for reporting. One of the main features required is when financial data is entered into a form, the relevant information should be update in QuickBooks. Specifically, instead of filling out a donation slip, putting it into a file for a donator, bringing up Quickbooks and recording the donation they want to have an application where they enter the donation/donator info which is stored in a database and, using the Quickbooks SDK, updates the daily deposit/donations/etc info in QuickBooks automatically.
My boss is trying to convince me to make a custom application to handle the whole thing, but I've been considering trying to pitch an Infopath + Sharepoint solution to him for the form management. However, I have absolutely no experience with either, so I don't know if any kind of integration with Quickbooks would be possible. So would an integration infopath/sharepoint with Quickbooks be feasible, and can you give me tips on where to look for info on how to implement it. Also, hiring a 'SharePoint Developer' is out of the question. So would a VB.Net/C# developer who has experience with web application development be able to address the programming skills required for a solution?
I'm open to any ideas.
I believe a .NET developer could probably handle this situation. You could possibly write code in the Infopath forms themselves, or create SharePoint workflows (using Visual Studio). It would probably be a decently complex and hard to maintain solution though.
I have not expirience with Quickbooks... If Quickbooks has web services to perform operations you are interested in you most likely will be able to make InfoPath form to collect/submit data.
InfoPath alone (as client application part of Office) may be enough - you should be able to quiclky prototype form you have InfoPath installed. For server side rendering of the InfoPath forms you need Enterprise edition of the SharePoint Server - not sure if this task alone would justify the purchase.
Related
My client uses InfoPath form libraries. They want to phase out the use of InfoPath all together and replace it some alternative.
My idea is to implement custom forms for the same and host it within SharePoint, so that the users can have a web based alternative, in place of client application such InfoPath Form Filler.
What can be the best strategy to achieve this?
If you're sure they want to use browser forms, I'd start by investigating Forms9 and Nintex. I think Qdabra did a webinar on getting your data out of your existing InfoPath forms.
However it might be smart not to rush, since InfoPath is not disappearing for several years. New options are in the works. Microsoft is working on native solutions such as Forms On SharePoint Lists that might meet your client's needs in a year or two. Also Formotus (my company) has app-based form filling solutions and has announced the intent to continue superseding InfoPath, so the right solution may come from there too.
Recommended reading: My blog series on InfoPath Alternatives
http://www.formotus.com/category/infopath-alternatives
Is there a way to publish Infopath form manually? I have an infopath form that I created for sharepoint on a computer. Now, I want to move that xsn file to another dev computer where sharepoint is installed but no infopath. So, I cant use the infopath publish options. Is there a way to MANUALLY PUBLISH?
What I have tried so far is to open the xsn file and read the xsf file. That did not work.
Can someone please help me out?
Thanks,
Moving my comment to answer.
First, I did not understand what "MANUALLY" did mean... but forgot to ask.
My personal belief (from never ever sufficient experience) is that it is impossible to manually substitute the publishing (which is being done from Infopath Designer).
And the latter is proprietary undocumented about full details procedure dependent on sharepoint internals (with the latter also being proprietary and closed information).
Might be somebody else has another opinion.
Well, you can try... and report here back.
Update:
There are development suites (IDE, frameworks, extensions) where you can develop all from the scratch or use open source libraries, extensions (like .NET, MS SQL Server Business Intelligence) and the approaches where you should follow what is precompiled and closed for meddling like Sharepoint and Infopath.
There are pro and contra in both.
In any case one should analyze and balance business requirements.
Anyway, I was a little puzzled by situation when you do not have Infopath installed on client machine.
In this case, you can use Infopath forms only through Infopath Forms Services of Sharepoint Server which is enterprise and rather expensive feature.
If you (or your client have it), then Infopath (which is part of Microsoft Office suite) is usually already bundled into all Microsoft plans or packages having enterprise Sharepoint server.
There is also Office 365 (Sharepoint Online) 30-day free trials with all bundled.
Here is comparison of plans and prices.
When mine expired, I was getting warnings and proposals to buy but really continued to have access for more 4 months before my access was really cut.
It is a marketing bluff that Infopath is easy. It is easy to start by clicking a few buttons and generate something ready but this easiness pays off dearly if you will be required to do something more flexible, customizable and/or not reqadily provided OOTB (very frequently used term in Sharepoint and Infopath, Out-Of-The_Box) in Sharepoint and IP when it happens that it is more difficult, more time consuming and more involved then using development from scratch approaches
I have read very little content regarding Sharepoint (SP), and most of my reading has been sales pitch oriented overview material. I utilitze VBA with Office apps - especially Access - on a regular basis, and I am wondering if there is any translatable way to retain the custom functionality of writing my own VBA within Sharepoint, especially with MS Access.
I have read that Access databases can be run on SP, with tbales to list and forms to InfoPath, but I am assuming they are primarily talking about Access database apps that were built with wizards, which consist mainly of bound objects without explicitly-defined code.
Most of my app are primarily code driven with VBA because of my automation requirements, which I rely on to perform my tasks. Am I going to be able to accomplish the same thing within SP, and could anyone please provide any references on the subject, specifically?
You can use Access to distribute your front end to users, regardless of how much VBA it has, but an app with VBA code in it will not convert to run in the browser as a Web Database within Sharepoint 2010's Access Services. For that to work, you have to use the new, more powerful macros and limit yourself to the features supported by web objects. For an existing app, this means rebuilding every object from scratch.
Do you need to run your Access app in a web browser? If not, then you're barking up the wrong tree here.
AFAIK Sharepoint does not support VBA.
If you publish an Access database to SharePoint as a web database it cannot use VBA, however you can create a hybrid with the tables in SharePoint and the frontend in Access, that way you can have as much VBA etc as you want and still have the advantages of your data being stored in the SharePoint SQL server. You can store the frontend on SharePoint and have users download it through SharePoint .
The alternative is to keep a traditional Access database on the SharePoint share and access it via webDAV rather than the SharePoint web interface. You could map the SharePoint library as a local drive to make it easy.
Note that drive mapping is considered a legacy technology and will no longer be supported by Windows 11 due to the demise of IE11.
I am a .Net developer and I need to get started with SharePoint 2010 and InfoPath 2010 for a new project.
I believe I don't want too much SharePoint just the basic configuration and how to host an InfoPath form there. For InfoPath I need to know how to design forms and program it using VS2010.
I appreciate if you can provide me with some links/books to get started with SharePoint and InfoPath (with more emphasis on InfoPath development).
Edit
I really need some personalized advice instead of an entire website to surf. I will be totally lost like this.
As John alluded to - the path to learning really depends on your project needs.
My recommendation would be to learn InfoPath first. You don't need SharePoint and you don't even need Visual Studio to utilize the majority of InfoPath. You might be able to accomplish your goals right there without even delving into anything else.
If that is not enough start looking at the other things. You will need advanced programming (Visual Studio) if you are trying to customize the form experience for the user, adding functionality that is not available directly in InfoPath. Start looking down this path if you run into roadblocks with how you want your InfoPath form to work.
You will need SharePoint if you need a delivery mechanism, forms storage, tracking for the users. Start looking down this path if the forms start being complicated to manage on a file share (or if you need extra functionality like change tracking etc).
In general - start with Infopath and progress to the other things based on your needs. Programming is for the form (singular) experience, SharePoint is for the forms (plural) experience. Note also that they are not mutually exclusive - usually you end up needing both.
What are the Benefits of using InfoPath forms in SharePoint?
I’ve been doing research on InfoPath to see how it integrates with SharePoint. The idea of letting users create their own forms offers a lot of power, and could enable people to handle some of the small requests they have on their own. However, outside of creating a form library that is driven by an InfoPath form, InfoPath appears to quickly become a hassle and a hindrance. Sure you can build code to directly talk to the SharePoint Object Model, but then you can only seem to be able to run your forms in the browser.
If you’re going to run everything in the browser, why not just use an ASP.NET form?
Also, besides the basic forms library approach, what other benefits does InfoPath on SharePoint offer?
I like to think of Infopath forms as being a great solution to the age old "form in a word doc" issue that companies have. It moves the task of creating and modifying forms closer to the people who care about the information.
There are tasks that are difficult to achieve in Infopath, but again it depends on the knowledge of the person creating the form more than the technology itself.
For forms that are complex and/or require large throughput, a straight ASP.NET form would be a better fit. As always it is about choosing the correct (cheapest total cost?) technology to solve a problem rather than shoehorning a solution from whatever is lying around.
(i.e. I still don't know enough about InfoPath to make a decision easily all the time).
Here are a few benefits of InfoPath forms over ASP.Net forms.This will, of course, always depend on your mix of requirements, developers, user skill, etc.
Forms are simple to create and modify for people familiar with MS Office
They integrate directly with the metadata in Sharepoint, unlike an ASP.Net form
Workflow Foundation is available through Sharepoint and simpler than using an ASP.Net form
If you're dealing with document-based processes (like work orders, orders, permission requests), it might make more sense to have a repository of the documents, rather than building a reporting structure off the data entered through the ASP.Net form
The documents are ready to be used by a process implemented in BizTalk
The validation and logic are run on the client with no additional programming, many times giving a much better user experience than plain ASP.Net forms