I am new customer who is considering the purchase of the SDK to make some minor alterations to form appearances and functionality in preparation for our company's Go-Live.
We need some candid feedback about the pro's and con's of using the tool, especially the availability of documentation, lessons learned, etc...
Internally, we have resources available to us with a few years of both Visual Basic and Java experience. Is there an advantage of adopting one language over another?
Are there hidden costs?
Is there gross functionality that the SDK simply cannot perform.
How difficult is it to learn the objects and deployment methods for the tool, assuming the developer has a solid OO background?
Thank you for any and all feedback...
Scott Young
2 Answers
-
Best Answer
Former MemberPosted on Feb 23, 2005 at 06:08 PMJohn, thank you the time you spent in providing this reply.
While I'm pretty sure I am ready to recommend purchase of the tool to our small company, there are a few straggling questions about specific projects we would perform. I'm not looking for "how to" answers, only whether or not anyone sees limitations in the SDK for doing these projects. The projects include:
(1) Tying "cost" of a sales order to an invoice for non-stock items (to be drop shipped to a customer). We are a manufacturer's representative; and, the cost on a sales order must be estimated before the factory builds the product we are selling (big, custom industrial boilers .... exciting stuff, eh?). Especially due to the wild fluctuations in the price of steel, we regularly see changes to the P.O.'s invoice associated with a particular Sales Order. However, we there is no tie between a purchase order's true cost to the company and the original Sales Order for our gross margin calculations associated with every deal. Can we programmatically fix this or will we encounter one of the few limitations of the SDK?
(2) Setting several fields as invisible by "role" within the company, since there are certain fields that should only be modified by particular individuals in the company, yet we still need to expose most properties of objects to people within specified roles (e.g. a Business Partner). No "role"-based setup exists in the system; so, do we have to perform this on a user-by-user basis? Regarding the visibility of certain controls, I "believe" this is accomplished by unsetting the "visible" property of form object widgets. Is this correct for SBO?
(3) Creating a process to allow us to handle a quirky drop ship factory order workflow from a specific vendor. We receive an order for a boiler from a customer. Create the sales order with this customer as the BP. From the sales order, we create a P.O. to the factory for the order. Then, "the factory" invoices the customer and collects payment, sending a commission to us. Therefore, the receivable to us is not from the actual customer, which we want to track in our bookings reports as from the factor. One would think we should then put the factory in as the BP for a Sales Order. That doesn't work since we need to be able to track who the customer is for our orders. We need to be able to go to a BP record and have the link to this sales order for future reference/work, e.g. future warranty opportunities, simply our knowledge of this order for this customer, etc.... We can't create a "wing" account under the factory's BP record for this customer since the customer may buy product from other factories in the future.
(4) Add vendor list price column (from a price list) to each item on a quote and sales order. This is "not" the cost to us or the customer, which are on other price lists. Add the customer's discount %, a calculation using this vendor list price and the sale price to each item on a quote and sales order. Then, we would also need this information for our quote templates that we would create for printing this information for customers.
Thank you in advance for any comments that might assist us in understanding if the SDK can handle these requirements!
Regards,
Scott Young
Add comment
-
Former MemberPosted on Feb 23, 2005 at 12:04 AM
You can have a look at the documentation yourself, it is now available in the Business One developer area of SDN - look for the "One-stop shop for Business One SDK Help Files, Technical documentation" link. This contains the new Help Center front end that provides links into the various documentation / help files provided with the SDK.
If your choice is between VB and Java, I would go for VB. All the samples and documentation are available for VB. Java is really only really supported through a Java connector for the Data Interface, not for the user interface.
Assuming that you already have appropriate full user licenses for your end users, and purchase the SDK for your developers, I am not aware of any other hidden costs.
There are certain things the SDK cannot do. In particular it is designed so that you should not be able to break the core data integrity rules of the business objects eg. Raise a sales order item with an invalid product code.
You can interact with the Business Objects with the Data Interface, and Interact with the Client software using the User Interface. You can create/amend screens, menus etc, intercept keystokes, mouse clicks etc. You can introduce code before or after standard business one events and also control whether standard business one events are executed or not. There are a few business objects not exposed by the SDK, but a Recordset object is included for accessing these. Printing support is pretty much non-existant in the current release, and some of the "fancier" grid controls that you see in the product are not yet supported in the SDK.
The SDK is fairly easy to learn, there are formal SAP training courses and certification available if you want. This forum can also be a useful source to those new to the SDK.
Hope this helps,
John.
Add comment
Add comment