I have a rails app that takes care of all the bank transactions for us. Our accountant wants all those to be automatically imported into Quickbooks Pro (either online or desktop version).
I've read about Web Connector and Transaction Pro Importer, but I feel like I don't have enough info to make a decision. I'd appreciate any advice!
Thanks!
For QuickBooks for Windows:
If you're a developer, and you're comfortable with developing with some SOAP components, the Web Connector will be a good direction to go for you.
There's some pretty decent Web Connector Ruby gems out there already:
https://www.google.com/search?q=ruby+quickbooks+web+connector
If you're not a developer and/or don't want to develop something yourself, Transaction Pro makes things relatively easy to import/export.
For QuickBooks Online:
For SaaS applications, the QuickBooks Online APIs are very good. For non-SaaS applications, you have to use the qbXML gateway for QuickBooks Online, which is somewhat limiting sometimes. In your particular scenario (you're not a SaaS app allowing your customers to connect their QB files to your app) you'd be better off with QuickBooks for Windows.
Related
We currently need a portal solution. One of our service providers has already suggested that we develop the portal in Apache OFBiz.
Now I would like to know if Apache OFBiz is still state of the art or if it is already on the way down.
Or is there another technology we should consider.
Best Regards,
Foerstar
Apache OFBiz is a solid Open Source framework that is actively maintained and updated by its community that is part of the Apache Software Foundation.
While the OFBiz architecture has been outlined years ago, it is still a modern framework that incorporates several pragmatic patterns and is designed to be flexible and extendable. Moreover various components and technologies have been kept up to date or replaced with newer ones over the years.
It is impossible to tell you if OFBiz is a good fit for your portal solution because I don't know your specific needs but my recommendation is to at least consider it especially if in your portal you will publish content related to products or other business entities: if this is the case then the OFBiz universal data model will be a valuable resource that will help you to achieve your goals efficiently and with high quality.
I am building a UWP app that targets both x86, x64 and ARM platforms. I want to replace the current implementation that uses Azure for the backed (an App Service and an SQL Server) because of the high price and because my Pay-As-You-Go subscription does not allow me to set a spending limit.
I thought about using a local database but I don't know if that could be a solution since I want the user to be able to have his data synced on both PC and phone for example. I am also ok with renouncing the idea of a structured database in favor of structured files (like xml) if I can find a way to keep them somewhere in the cloud (and then I can read/write them from the client app - no need for App Service).
Are there any free, non-trial alternatives to Azure? Or should I look more into the file storage implementation? Thanks in advance.
Instead of Azure you could use another web hosting solution to publish you API. Azure also offers small free plans that might be sufficient.
An alternative would be to request access and store/sync data to user's OneDrive. Each logged in user with Microsoft Account should have OneDrive storage available so this is a good middle-ground, which is still free for you. A nice introduction to this can be found in this article.
UWP also offers RoamingFolder where you can store small files that are synced across the devices that you use. Unfortunately this is less reliable because you are not able to control when the sync happens and cannot resolve conflicts.
I have successfully migrated to another cloud platform: Heroku. In my opinion, at least for small apps, Heroku offers the best solution both technology-wise and price-wise.
I am now able to have a webservice hosted for free in the cloud, without worring about traffic and number of requests. Of course you can scale up if you want better performance, but you can start with a free plan. Also, I have a postgressql db hosted also in the cloud, also for free (up until 10 000 records, and it will be just 9$/month if I want to upgrade to 10 milion). One can never found an offer like this free on Azure.
I had to learn a bit of Node.js (there are a lot of languages Heroku supports for backend services, but .Net is not one of them) but it was totally worth it!
Another option that is now starting to gain more and more popularity is FireBase. I will certantly also check that out for my future apps.
We're planning to develop a web based Healthcare Practice Management System. Due to HIPAA we're requested to deploy the app in our own premises. Our company is relatively small currently we have only software engineers and no devops engineers but still we want to develop the application to support horizontal scaling(adding more servers).
Planned to use:
Python3 (Django)
PostgreSQL
I'm looking for something like AppScale but with the freedom of choosing our own runtime, database and frameworks.
In other words from the software engineer's perspective:
Should provide an easy way to deploy django application
Should have web based dashboard to monitor and control(like AppScale)
Should make load balancing simple (app and database)
AppScale implements the Google App Engine APIs which, IMHO, make it super easy to develop web apps quickly and efficiently.
On top of that, you get auto-scaling, load balancing, and the ability to deploy on-premises and plug in any third-party library you need.
AppScale already comes with a dashboard and will soon be launching a new management service for your AppScale deployment(s).
If you're not particularly hung up on Python3 and PostgreSQL, all of the above seem to cover your requirements.
It's worth noting that opting for the GAE model means you opt for NoSQL and, so, postgres is probably not the best option.
Disclaimer: I'm part of the AppScale team and we're already helping companies develop and deliver their apps in the HIPAA compliance realm.
I chose Kubernetes which is a container orchestration technology specifically designed for Docker and also found that scaling is not just the responsibility of platform that the app is deployed on but also its depends on how the app is designed and coded. For that The Twelve-Factor App methodology is really helpful.
But I can't deploy database on Kubernetes because its not recommended by Kelsey Hightower(author of Kubernetes Up and Running) in his talk. So, for now I chose to deploy my database on a VM.
I am working in ektron 8.6.
I am trying to connect a third party enterprise systems to ektron.
DxH has got a pre-built marketing automation connector,which is Marketo.
My third party enterprise connector is also a marketing automation system.
I am following the developer webinar to get this done.
Now,my question is eventhough i made establishing connection to the third party system by means of ConextBus API,i need to make some changes in the workarea files for implementing certain functionalities.
So is it necessary to have the connection established via DxH?
What is the significance of this compared to handling all these functionalities from the ektron site?
Can anyone provide me some insight on this?
If you're asking "why use DxH?" the main answer is its tight integration with Ektron. You can continue using your marketing automation system and it will share relevant data with Ektron. If you are instead looking to perform a wholesale migration away from a particular system, you can certainly do a one-time import of data into Ektron using the APIs. The difference there is that you would be moving away from the 3rd party system, whereas the DxH and its ContextBus allows both systems to work together.
You mentioned a webinar that you are following, so you may have already seen this, but there's a good webinar on the DxH here: http://www.ektron.com/Webinars/Details/Digital-Experience-Hub---Developer-Webinar/
I am in the process of integrating our custom web app with QuickBooks Enterprise 9. My thought is that I could use QuickBooks as my "database" of sorts. When a person creates an invoice, the invoice is actually stored only in QuickBooks. When a person views a list of invoices, they are actually viewing a list of QuickBooks invoices. I want to make sure the data is stored in only one location.
I realize that I could use the QB Web Connector, but the problem with that is I wouldn't have control over when the requests to QB actually get processed (That job is up to the Web Connector).
So I have my web UI to act as the QuickBooks "face," but I don't have any good way to get to and from the QuickBooks file located on an internal server. What I was thinking was that I could create a WCF web service and install it on the QuickBooks server. The web service could then be my integration point. My custom web app could then consume the web service and, viola, I have access to my QuickBooks files.
My question is this: Can a WCF app connect and run QuickBooks? If not, could i create a Windows service to act as my point of integration? If so, can my custom web app "consume" a windows service?
I'll start by warning you that QuickBooks probably isn't your best choice for a reliable back-end database accessible from a remote website. In fact... it's probably a really, really bad choice.
You should have your own application database, and then if you need to also exchange data with QuickBooks, do that outside of the normal lifecycle of your app, as a separate sync process.
QuickBooks generally isn't reliable enough for always-online type of applications due to a number of reasons:
Flaky SDK connections
Updates and single-user mode will
lock you out of accessing QuickBooks
Difficulty in establishing SDK connections from non-GUI processes (Windows Services and IIS processes)
With that said...
Yes, you could create a WCF web service, host it on the QuickBooks machine, and make your WCF web service relay messages to/from QuickBooks.
Yes, you could also create a Windows Service that does the same sort of thing.
Do NOT implement it as a Windows service, and do NOT implement it within IIS - instead implement it as a GUI app that runs alongside QuickBooks.
If you try to implement things as a Windows service or within IIS, the QuickBooks SDK requires you have a GUI available (it users a GUI COM message pump for events dispatching or something like that...) to process requests, so you'll probably need to use something like QBXMLRP2e.exe to straddle the process boundary between QuickBooks and your non-GUI Windows service/IIS. My experience has been that it's a gigantic pain in the butt, and requires mucking with DCOM permissions as well.
I have an example and some documentation on my QuickBooks integration wiki.
The IDN Forums are a good place to ask questions.
My recommendation to you would be to either:
Use the Web Connector and QuickBooks
and give up hope of keeping all of your data in one place. Cache the data in a real database, and update it by querying QuickBooks periodically. I'm almost done building a solution to do exactly this right now, and it works fantastic.
OR
Use a different account system. NetSuite is pretty nice. I'm not sure what else is out there, but if I were you I'd look for something SQL-based or with a strong SOAP/REST API.