OK, Invoices were easy
I now have the following syncing from Tony's application into Quick Books:
- Items
- Services
- Customers
- Vendors
- Accounts as needed
- SalesTax as needed
- Work Orders
- Purchase Orders (just coded, not tested yet)
Leaving just a few items:
- Special Orders (really just a purchase order, but fed from a different table).
- Sales Payments
- Purchase Payments
Anyway, invoices ended up being the better of the two things I thought might happen. All of the difficult stuff was already done in syncing the other objects. I needed to add some new code for Accounts, but it was almost a complete rip-off of other code I had already written. Also, started adding some better error tracking in my code. Was getting a little frustrating not knowing why things were failing.
The major upside of this whole project is that the Quick Books adapter I've written is pretty much completely reusable. I think I need to change namespaces and perhaps go back over the first couple methods I wrote to get them up to the same standards as the later methods.
So, I'm hating the Quick Books integration less the more I work with it. I still think it is written in quite a silly fashion. And honestly, most of what I'm starting to stop hating about it is the result of helper methods I've implemented around their libraries to make them actually sensible. The kinds of things I've implemented are so astoundingly simple and make the experience so much better, I'm really completely baffled as to why these aren't the sort of things that they would have included in the API by default. In one case, they have actually created their own helper methods which they put in their sample code that should really be included in the core. It is a big, boring method that retrieves a message request coded for the appropriate version of Quick Books based on the Company File you've connected your session to. Why the hell would you force every developer to re-implement that exact same boring piece of code for every application they write?
Anyway, done for the day I think.
- Items
- Services
- Customers
- Vendors
- Accounts as needed
- SalesTax as needed
- Work Orders
- Purchase Orders (just coded, not tested yet)
Leaving just a few items:
- Special Orders (really just a purchase order, but fed from a different table).
- Sales Payments
- Purchase Payments
Anyway, invoices ended up being the better of the two things I thought might happen. All of the difficult stuff was already done in syncing the other objects. I needed to add some new code for Accounts, but it was almost a complete rip-off of other code I had already written. Also, started adding some better error tracking in my code. Was getting a little frustrating not knowing why things were failing.
The major upside of this whole project is that the Quick Books adapter I've written is pretty much completely reusable. I think I need to change namespaces and perhaps go back over the first couple methods I wrote to get them up to the same standards as the later methods.
So, I'm hating the Quick Books integration less the more I work with it. I still think it is written in quite a silly fashion. And honestly, most of what I'm starting to stop hating about it is the result of helper methods I've implemented around their libraries to make them actually sensible. The kinds of things I've implemented are so astoundingly simple and make the experience so much better, I'm really completely baffled as to why these aren't the sort of things that they would have included in the API by default. In one case, they have actually created their own helper methods which they put in their sample code that should really be included in the core. It is a big, boring method that retrieves a message request coded for the appropriate version of Quick Books based on the Company File you've connected your session to. Why the hell would you force every developer to re-implement that exact same boring piece of code for every application they write?
Anyway, done for the day I think.
Comments
Post a Comment