From talking to tech support I know that this is not the first request for LandFX to be interfaced with an accounting system. The system I use and will be selling to the green industry is a package called OpenPro (http://www.openpro.com). However, rather than writing to a specific platform, why don't you just create an API and allow any user who needs this feature to take the api and write something over on the accounting software side instead. That way it wouldn't matter what accounting software package was used. You would offer an api for a programmer over on the accounting software side to write to the API I am specifically interested in storing projects in our accounting system's Customer Relationship Manager module under a particular customer's account, and calling those projects up in LandFX and being able to do quotes from the CRM module using inventory from Open Pro's accounting inventory system based off of the bill of materials generated from LandFX. I would like the LandFX projects to be stored in our CRM system (it is a hosted solution) This way all customer information is stored and managed with-in the CRM system. (OpenPro has a build-in document imaging system. This allows for all contracts, emails, phone conversations, quotes, projects (openpro includes project management), engineering drawings (landscape designs) and invoices, to be stored under each customer account. This is a more intelligent method of keeping up with what is going on with each customer.
Steve,
We have already engineered the capability to post the plant schedule to any conceivable cloud-based provider.
Were we to develop an API, it would still require a company like OpenPro to engineer something to connect to it. But more importantly, we do not have the desire to slow down the plant schedule feature for the needless purpose of uploading quantities. Should a user wish to upload the quantities in question, they should have to select something, and we feel they should have to select where they want them uploaded to.
You are welcome to have OpenPro contact us with a suitable URL and data schema for uploading plant schedule data. Once finalized, it would simply be an option in the plant schedule dialog box.
—J
We have already engineered the capability to post the plant schedule to any conceivable cloud-based provider.
Were we to develop an API, it would still require a company like OpenPro to engineer something to connect to it. But more importantly, we do not have the desire to slow down the plant schedule feature for the needless purpose of uploading quantities. Should a user wish to upload the quantities in question, they should have to select something, and we feel they should have to select where they want them uploaded to.
You are welcome to have OpenPro contact us with a suitable URL and data schema for uploading plant schedule data. Once finalized, it would simply be an option in the plant schedule dialog box.
—J
So we have web pages now that collect data that customer’s enter on those pages and that data is directly transferred via a SOAP routine directly to our CRM system. Is what your suggesting accomplished the same way? By the way I realize if you develop.a API for all accounting packages that programming must be done over on the accounting software side. But that is where it should be done and the API once written would eliminate the need to address future requests from customer’s on this issue... just saying...
I guess it would be somewhat similar to that, yes. In that the knowledge that customers are entering exists only in their head, so they are in effect pushing it into the CRM system. In the same way, the plant quantities exist only in the plan, within an AutoCAD session. So those quantities need to be pushed somewhere.
If we were develop an API, this would be a two-step process, of first uploading the quantities to landfx.com. Then separately going into your CRM, and pulling the values down
The API does not reduce any complexity or programming needs. For literally the same amount of effort, a company like Open Pro could configure the ability to receive these quantities directly into their system. We would still establish the parameters and data schema, very similar to an API. Our preference would be JSON and REST, using OAUTH2, rather than having to support a standard like SOAP that is on its way out.
But it’s all engineered and ready, they can drop us a line anytime.
—J
If we were develop an API, this would be a two-step process, of first uploading the quantities to landfx.com. Then separately going into your CRM, and pulling the values down
The API does not reduce any complexity or programming needs. For literally the same amount of effort, a company like Open Pro could configure the ability to receive these quantities directly into their system. We would still establish the parameters and data schema, very similar to an API. Our preference would be JSON and REST, using OAUTH2, rather than having to support a standard like SOAP that is on its way out.
But it’s all engineered and ready, they can drop us a line anytime.
—J
I hear so many programmers lamenting the imminent death of PHP in favor of java and node JS and yet all the major code of the internet is still using PHP... if I had a nickel for everyone who claimed PHP is dead I would be rich indeed! When node JS has as many years and applications notched on it’s pistol grip as PHP has I will concede defeat... but until then PHP still remains KING. And these other languages remain POTENTIAL up and comers... me too’res at best... I will have the folks at OpenPro get in touch
So one issue will be the lack of part numbers associated with the items in the plant database. (or do you have such an ID that I am not aware of?) We would need a database field with a unique id for each item within your plant database. Our inventory system can use you as a supplier and your unique id for each plant in the database. We then associate that ID with a part number within our inventory system. From there we can generate the quote in CRM after working out the details of communication between LandFX and Open Pro. Also can we get a data dump of your plant database?
There is no reason for us to store every conceivable SKU number in our database. The plant information would be posted to your system. Any new plants could then be assigned inventory numbers. The unique identifier is the Plant Code. Since the system would need to be able to adapt to new plants and changing inventory numbers, that is the best way to design the system -- the plant information and quantities are posted to your system, and everything else happens on your end.
--J
--J
- Page :
- 1
There are no replies made for this post yet.
Contact
- Land F/X
Our software tailors AutoCAD® to the needs of landscape architects, irrigation designers, and other professionals. We automate your most tedious tasks and ensure accuracy, giving you more time to design.