all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Yellow
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On a phone call with Steve for about an hour. We were talking about a number of different things and topics. Here are some of the topics: - What about a new cart template that shows the possible subs when a quote is restored to the cart. Basically, we know the parent items or even the quoted subs. What if we just showed that or those options and let the user choose what was real and needed to be on the invoice? That would really speed up the process and take away the need to remove so many line items. - What would happen if we went to a one-to-many relationship on the API socket settings and the adilas 3rd Party Solutions page? It would be cool to expand the API to allow multiple different people to use it based off of different criteria and settings. The other idea is auto turn API sockets on/off based off of actions done on the adilas 3rd Party Solutions page. That would be cool. As a note, we would need to disclose what was being turned on/off if they didn't specifically open or close certain API sockets or virtual windows. - Steve and I talked about the old saying - static vs. dynamic. Then Steve said, "We are way past the dynamic level or stage. We are into fracturing." Basically, the further we go out, the more sub levels of control that are needed. Every main item or topic inside of adilas is splitting and virtually fracturing into smaller and smaller controls. There is also some requests to standardize and make bulk decisions based off of known needs. - We need to adopt the strategy of fracturing and even embrace it. Let everything go into the subs or sub levels. - Still on normal dynamics vs. fracturing & breaking into subs - The old way of normal dynamics has a element of planning and then building accordingly. Once it starts to fracture, split, and break, some of the planning gives way to being driven or being forced into new changes. We have to start reacting vs. the proactive slow growth model. Things have to be built and then be used. The more mature they get, the more they tend to start fracturing and splitting. - We are so glad that we have built off of a relational model that included one-to-many, as deep as we need to go. - We are getting more calls for sub part categories and pushing sub inventory out to the ecommerce levels. Things just keep on going. After the phone call, we then spent 1.25 hours working on sub inventory and trying to get some things fixed that were the problems or open holes. We fixed some formatting for quantities, some multiple decimal levels on costs, and then closed an edit hole that allowed a user to edit a parent part number from a PO line item form. Pushed up some new code. |