Search The Adilas.biz Developer's Notebook
Time Period:
Daily (enter the day you want to see)
Monthly
Custom Date Range to
Template Filter:
Color Code:
General Text Filter:

(use a plus "+" sign to separate search terms. ex: jack+jill+hill)
Sort Value:
 
Adilas.biz Developer's Notebook Report - 3/1/2009 to 3/31/2009 - (32)
Photos
Time Id Color Title/Caption Start Date   Notes
Click to view time photos.
AU 1299 Daily Tasks 3/2/2009   • Went in to work with an associate. 10 miles.
• Brainstorming on work in progress and aged invoice.
• On the phone with Steve.
 
Click to view time photos.
AU 1300 Daily Tasks 3/3/2009   • Working on verifying invoices when deposits get verified.
• Worked on a global update page.
• Posted files.
• Ran deposit/invoice update page.
• Backed up the database.
 
Click to view time photos.
AU 1301 Daily Tasks 3/4/2009   • Working on balance sheet and using the verified date vs. the basic dates. Basically, cash vs. accrual.
• Made work in progress stuff go live.
• Went in to town and worked with a contact who was an auditor in Washington DC. Demoed him on the adilas system, it was a good meeting. 10 miles.
 
Click to view time photos.
AU 1302 Daily Tasks 3/5/2009   • Working on help files and checking off pages.
• Working on printer friendly invoices and moved the customer info up to its own table.
• Signing off on pages and working on printer friendly invoice page.
• Posted files.
• Emails and phone calls to set up appointments and get confirmations on things.
• An associate came over and we did some training in adilas. We did make, models, units and PO and parts invoices.
• Went in to meet with an associate about adilas numbers. Went over some cash vs. accrual info. 10 miles.
 
Click to view time photos.
AU 1303 Daily Tasks 3/6/2009   • Went in to town to meet with a company. Gave a demo to both of them. Talked about work options for adilas. 10 miles.
• On the phone with Steve giving him an update and talking about the direction that we need to go to finish up some things and get things set-up. Also talked about taxes and what we want to do with adilas as a company on taxes.
 
Click to view time photos.
AU 1304 Daily Tasks 3/7/2009   • Planning the day and what is needed for work in progress and adilas taxes.
• Working on new bank pages and how things are calculated.
• Updated bad pmnts. Worked on showing outstanding deposits and checks for verified bank totals.
 
Click to view time photos.
AU 1305 Daily Tasks 3/9/2009   • Working on outstanding bank balances.
• Started working on I.S. and B.S. going through step by step.
• Working on cash vs. accrual.
• Worked on deposits that slip through the cracks when working on a cash basis.
 
Click to view time photos.
AU 1323 Daily Ideas 3/9/2009   Plan for I.S. and B.S. Rework Session “Cash”:
1. Start with banks. Leave basic dates “as is”. On verified dates, change current logic to also include outstanding deposits and outstanding check/pmts.
2. Create new bank reports and show outstanding values. Quick and dirty.
3. Include new outstanding items links (drill-downs) from bank homepage, add/edit, bank page, running bank balance page, and B.S. drill-downs.
4. On I.S. I need the following changes: Some of these need to be done today and some by first of next week.
o Deposits made and invoices not yet marked verified.
o Work in progress – look-back compatible.
o Expenses that are tied to a bank but not yet verified.
5. On B.S. I need the following changes:
o Outstanding values for banks with a drill-down.
o Work in progress inventory (Dom’s?)
o Need major help with what to do with inventory on a cash basis. Inventory doesn’t run on a cash basis.
6. Standardize the date switch between basic dates and verified dates. Currently one section is 1 & 2 & the other section (B.S.) is 2 & 1. Need to keep things consistent.
7. Not related to above, but check for “mode=add” and the capitalization of Add new links.
 
Click to view time photos.
AU 1306 Daily Tasks 3/10/2009   • Went in to town to work with an associate on a balance sheet. Saw their work and told them I would set up a meeting to help out. 10 miles.
• Working on adilas bank stuff. First time going through bank statements and doing an actual deposit.
• Working on showing values on the income statement on a cash basis. Added a section with its own drill-down reports for deposited non-verified invoices.
 
Click to view time photos.
AU 1307 Daily Tasks 3/11/2009   • On the phone with a customer going over bank balances and possible problems.
• Added new search filters on the advanced receipt payment search page.
• Worked on the invoice payments not yet deposited page for balance sheet drill-downs.
• Worked on showing non-verified expense types on the income statement.
 
Click to view time photos.
AU 1308 Daily Tasks 3/12/2009   • Working on non-verified expenses and running things on a cash basis.
• Working on work in progress invoices and printing with no costs.
• Posted files online and added new help files.
 
Click to view time photos.
AU 1309 Daily Tasks 3/14/2009   • Working on work in progress invoices and how they relate to receivables.
• On the phone with Steve talking about ideas for builds and work in progress stuff.
• Working on showing W.I.P. invoices on the balance sheet.
• On the phone with Steve asking questions about how to handle WIP invoices, costs, inventory and payments.
 
Click to view time photos.
AU 1310 Daily Tasks 3/16/2009   • Research on cash vs. accrual accounting.
• Went in to work with Steve on work in progress invoices and how to show them on the balance sheet. We also did some brainstorming on recipe/builds. 10 miles.
• Working on WIP invoices and how to show them on the balance sheet.
 
Click to view time photos.
AU 1311 Daily Tasks 3/17/2009   • Working on how to show WIP invoices on the balance sheet.
• Tested pages and flow.
• A contact came over to work on adilas training. Went through units, invoices and expense/receipts.
• On the phone with Steve going over job descriptions and who we can get to help us out. Talked about possible clients and leads.
 
Click to view time photos.
AU 1324 Daily Ideas 3/17/2009   -On lien pay offs – set the cost to the value of payoff. Liens will need to lead to payables eventually.
Recipe types:
1. Build & Sell: On the fly –quick
2. Build & Hold: Build and keep, build and stock
3. Build & build: Build and morph
-Be able to set the tax category on a recipe.
-On parts – be able to choose a default tax category.
-On recipes – include different permissions:
- Basic: able to see and also able to search by recipe on add items or parts homepage
- Add/edit: admin level
-On build and sell: Have the main part be a $0.00 cost and unlimited qty. then all the other pieces are hidden or blind line items with actual costs. The additional line items can be shown or not shown depending on what is needed.
-On parts & PO’s – Need a way to combine vendors. Have a known problem with parts, PO’s, invoices and vendors. A vendor may become inactive but it still has parts, PO’s and expense receipts tied to it. We need a way to combine or merge records together. This can get deep because the vendor id is tied into tons of different places. The problem gets worse because of each part-id that is tied in different places in the site.
 
Click to view time photos.
AU 1312 Daily Tasks 3/18/2009   • Research, phone calls and messages to some companies.
• Emails to Steve and an associate about demos and Texas trip.
• Working on known issues and PO payments. The problem was with what dates to use.
• Went it to submit the adilas tax stuff. 10 miles.
• Working on PO payment problem and adding vendor/payee and receipt date to expense/receipt advanced line items search.
 
Click to view time photos.
AU 1313 Daily Tasks 3/19/2009   • Working on unit payments and what dates to use when paying.
 
Click to view time photos.
AU 1314 Daily Tasks 3/20/2009   • On the phone with Steve going over bank balance stuff.
• Went in to work on balance sheet stuff. Worked with Steve and another associate on different tasks. Talked to the associate about payroll and quarterly reports. 10 miles.
• Working on applying payments and making sure the dates were correct.
• Made some changes to the balance sheet home page.
• Made the user maintained items show-up in a more simple format.
 
Click to view time photos.
AU 1315 Daily Tasks 3/21/2009   • Working on the user maintained balance sheet homepage. Working on the WIP invoices and where they need to show up or not show up on I.S. and B.S. reports.
 
Click to view time photos.
AU 1325 Daily Ideas 3/21/2009   -Known problem with po_invoice_line_items and the 3 decimal places. Was decimal (9, 3) needs to be decimal (9, 2).
 
Click to view time photos.
AU 1316 Daily Tasks 3/23/2009   Working on WIP invoice stuff. Checking dates on PO and invoices.
• An associate came over and we did some expense/receipt training. We did some practice with expenses.
• Helped another associate with an invoice and vendor problem and launched the WIP files.
 
Click to view time photos.
AU 1317 Daily Tasks 3/24/2009   • Phone calls and emails to two customers.
• Working on the WIP invoice drill-down report. Posted files online.
• On the phone with a customer and wrote an email to show Steve notes about the conversation.
• Brainstorming and going over builds and recipes.
 
Click to view time photos.
AU 1326 Daily Ideas 3/24/2009   Ideas about audit trail and finding your transactions:
-Along with a history homepage, it might be really cool to show a page that shows transactions per day (date specific) but not tied to a history (date). Basically, according to dates, what changed or took effect that day. That would be really cool and could help with problem finding. Might need both cash (verified dates) and accrual basis.
 
Click to view time photos.
AU 2355 Brainstorming - Known Issues with Manufacturing - (Recipe/Builds) 3/24/2009   Known Issues with Manufacturing – (Recipe/Builds)
1. Manufacturing has a number of different names. Kits, kitting, macros, morphs, packages, work in progress, finished goods, builds, recipes, models, spec sheets, plans, drawings, custom products, assemblies, groups, deals, packages, deals, bundles, etc.
2. The name or word “manufacturing” is too limited. We want to be able to handle all kinds of products, services, new products, etc. Our scope may include companies that:
- Sell package deals
- Build new marketable products
- Allow options to be chosen on the fly
- Track inventory (raw goods) and also track finished products (builds)
- Possibly have unlimited levels of product assemblies
- Single line items (currently available in the system)
3. We want to be able to sell anything we want on a single invoice. This may include special line items, parts, units, labor, builds, hidden items, services, etc.
4. We need to be very careful and track quantities in, quantities out, raw inventory counts, finish goods counts, accurate costing, accurate pricing, etc. Most things are easy to put in… what about being able to void, back-out, credit, re-do, etc. We need to build the application so that it can go both forward and backward. To make this even trickier, we need to be date sensitive, location sensitive, and usable (easy).
5. What about table (database) capacity? What limits do we have? Are we painting ourselves into a corner or can we expand at will? What about pulling data back and loop size? Do we have any limits on ColdFusion or list lengths? Before we jump, we might want to scope it out. As it sits right now, we have plenty of room to run and see where it goes. This may be a subject that needs some attention in 6 months to a year.
6. I see manufacturing on a couple of different levels.
- Single (line by line)
- Apply as you go (say internal tickets to units)
- Single on demand (light and flexible)
- Multi on demand (light and flexible)
- Bulk (same thing over and over)
- Build from ground up (single or multi)
- Hardcore (building a serialized unit and placing other serialized units on that unit – track everything down to the “T”)
- Recipe types:
o Build & Sell: Shopping cart – type interface with flexibility to show/hide and add options.
o Build & Hold: Raw goods being combined to create a new part – this could be multi layers deep if needed.
o Build & Build: Similar to duplicating internal invoices but with a build and apply interface for serialized units. This might work well with mini units
7. What about batches, batch codes, process #’s, etc.? This gets into serialized units. Maybe we need a thing called a “mini unit”. This would be similar to a specific unit but scaled down and optimized for bulk creation, updates, and selling (all in bulk – yet specific with all of its history and batch numbers).
8. Do we want to create an actual build with a main and line items or do we want to use a PO and call it a build PO?
- Build Pros:
o New item
o Wouldn’t balloon up the PO table
o Wouldn’t change the PO numbering
o Could tie to a specific permission
o Could create custom logic and own history
- Build Cons:
o Additional development
o Full new section with add, edit, history, reports, etc.
o Need major changes to po_invoice_line_items table
- PO Pros:
o Logic is already in place for inventory control
o Smaller development time
- PO Cons:
o Permissions get a little trickier
o This would blow up the PO table
o Need to check all current PO logic
o PO’s are tied to payables
9. We would like to create a standalone item called a recipe. A recipe would contain all of the ingredients to make or build something. This could include qtys, prices, costs, descriptions, instructions, add-ons, options, etc. We would also like to include hidden line items and show output in a specific order.
- Other ideas on recipes:
o Prep time
o How long (duration of time)
o Yield (qty or output)
o Inventory check (do we have enough stuff)
o Output (what does it make or what do we call it)
o Amounts (qty & costs)
o Add-ons & options
o Order of ingredients
o Instructions
o Required items or optional items (choices)
o Active and inactive line status
o Prep (extra instruction that may be deleted later on or hidden)
o Flexible and user-maintained
o Able to search or look-up quickly
o Tax category (default per line)
10. We need a flexible invoice that can show all the details or just the items that need to be shown (show/hide status). Along with that, we also need to show a single invoice with cost and profit showing. Another way of saying this: customer view vs. shop view vs. back-end view vs. accounting view. All of these items (invoice views) need to contain the same info but may be viewed differently or only by permission.
11. On mini units, how do we track things in bulk yet keep things tied at the hip. This could be a nightmare. We want specific results but no one in their right mind would check 1,000 bolts for a heat code before using them. It seems like a natural disconnect. Good in theory (track everything) but just a shot in the dark in real life. Even if we did make something like this, how do we include checks and balances, quality control, and audits?
12. What about builds (runs). Say for example, we do a build and take 1,000 widgets and paint them or squeeze them into something (changed from the original). We then want to record the build number on all new widgets. Say we also put all 1,000 new widgets into a box and label the box with the build #. Here are a couple questions I would have:
- How do we (the system) tie the build to the box #?
- How do we know all the items in the box came from the current build?
- What happens if there is a gap in time or things get mixed?
- What happens if we use 1,000 widgets and only get 950 out the other end? What happens to the other 50? What happens if the box is incomplete? What if we over produce and have excess (but not enough to make the next box)?
- What happens to flaws, seconds, and scrap? What if one resale them?
- I would imagine that the box (see example in #12) would need the build #, maybe a user maintained build number (date or user code), plus its own port #. The part # would be unique for the end product but not for each box. This would require a multi-part key id (build and user maintained build and part id). My question would be, where do we record those extra fields? Do they get passed along and how do we tie-in or search them rapidly?
13. What about other manufacturing terms: lots, cases, boxes, bins, pallets, racks, loads, runs, cartons, packages, by weight, by size, by volume, sets, clusters, quantities, sizes, groups, collections, bundles, lots, baskets, buckets, bags, stacks, other measurements, liquids, solids, gases, jars, tubes, etc.?
14. What are the differences between manufacturing for internal, for re-sale, for retail, for other? What is needed on the build? What is needed on the finish goods?
15. What about verifying builds? What about payment options? Internal? Payables? $0.00 cost? Not sure.
16. What about roll-backs, voids, and dis-assemblies? This needs to be part of the solution but we also want to control how fast and how deep (levels) the action goes.
17. If you are building and creating, building and creating, etc. How do you keep a running log of what came from where? Parent /child relationships. Do we want to let the users create their own logs (separate table) that can be tied to any PO (build) or any unit? This would be a one to many relationship that could be classified as parent or child. Just an idea… we might be able to use this to tie a single box to multiple serial #’s or invoices. Maybe this parent/child relationship could be for build PO’s or invoices and tied back and forth however the user wants. Basically sell and build in bulk (keep it simple) and then allow the user to put in extra tie-ins that are flexible, searchable, and fully user maintained. We keep things simple and they (the users) add whatever detail(s) they need. This could be huge. It also could be super flexible. We may also want to include options for dynamic naming, multi add feature with a number field that would go from a start to end range.
18. Use the build PO to pull down raw counts and show new output all on the same PO.
19. See #17. Other ideas for the parent/child relationships.
- Maybe have 5 to 10 custom titles for parent/child relationships. Tie to a corp and allow them to update them at will. Basically, we create 10 text fields and name them like other_1, other_2, other_3, etc. In the background we allow the corps to set the verbage (titles) for each field. This way they could use any of the words in #13 and track whatever each corp needs.
- Maybe allow any extra fields to be hidden to make things look cleaner.
- Create a separate add/edit, add multi, search, and PO/invoice tie-in report.
20. Allow recipes to be searched like part numbers. Along with that, allow for parts, recipes, barcodes, and RFID tags all from the parts search field. Only show the non-parts options if the user has those permissions.
21. When doing builds how do we keep track of costs and prices?
- Cost options:
o Use current cost (from parts table) default
o Use fixed cost (hardcoded value) not recommended
o Calculate the cost (sum of all used ingredients) (only for recipe output)
- Price options:
o Use cost (see above for options) (internal or multi build)
o Use current price (from parts table) default
o Use fixed price (hardcoded value) not recommended
22. On the (additional tie-in and details) PO/invoice relationships (parent/child relationships) add an option to show/hide the relationships. If hidden, they will still be searchable and printable from the sub report page. If they are marked “show”. Show a list of subs below the main invoice details.
 
Click to view time photos.
AU 1318 Daily Tasks 3/25/2009   • Brainstorming on recipes and builds.
 
Click to view time photos.
AU 1319 Daily Tasks 3/26/2009   • On the phone with Steve going over builds.
• Brainstorming on recipes and builds.
 
Click to view time photos.
AU 2356 Brainstorming - Database Ideas for Recipe/Builds 3/26/2009   Database ideas for recipe/builds: (See scans in photo gallery)
Will need to run an update page to set default barcode, RFID, and tax categories for existing parts.
- Requirements for a build and hold recipe
o Must have at least one output or finished product. Must be visible or shown.
o Must have at least one ingredient or incoming item.
o Must have at least one shown item.
- Requirements for a build and sell recipe
o Must have at least one shown item.
o Must have at least one ingredient or incoming item.
 
Click to view time photos.
AU 1320 Daily Tasks 3/28/2009   • Went in to town to work with a contact on adilas. Another associate also met us there so that they could see the first live demo. Demoed the site and showed them around. 10 miles.
• Brainstorming on recipe/builds.
• Worked on tables and going over scenarios.
• On the phone with Steve going over builds and needs of our clients.
 
Click to view time photos.
AU 2357 Tech - Recipes Tables 3/28/2009   Recipes Table – (See scan in photo gallery)
Recipe Lines – (See scan in photo gallery)
 
Click to view time photos.
AU 1321 Daily Tasks 3/30/2009   • Research on Dimdim.com for web conferencing and software demos.
• Research on Crystal Tech prices and security options.
• Created some graphical concepts for adilas theory and training.
• Brainstorming on Recipe/Builds and database values.
 
Click to view time photos.
AU 2358 Brainstorming - Ideas for Adilas Theory & Visual Help Models 3/30/2009   Ideas for adilas theory and visual help models: (Lots of sketches & visuals – please see scans in photo gallery)
- Use the same models over and over again for consistency
- Money
o Money in: invoices, deposits
o Money out: expense/receipts, purchase orders
- Water – slush – ice
- Flat files vs. textured relationships
- Catch the data first… once we have the data… we can show it, modify it, and flip it if needed. For example: freight and doc fees, and taxes.
- Balance sheet – snap show in time. Maybe tie this to the analogy of cars and roads and parking lots. If the camera takes another shot in 10 minutes it will be different but may contain some of the same cars.
- Client/server with multi windows open.
- Tool kit – not every job uses a hammer. Different tools for different jobs.
- “Constant rolling month”
- “No Adjustments”, “No Journal Entries”, “All Data Is Live And Searchable”
- Let operations lead accounting not the other way around.
- “Catch the vision”
o Don’t worry about the absolute details…
- Less is more… if they want more detail… view additional files or ask for a demo.
- Think “Fishing”!
- Cash vs. accrual: 1 to 1 = cash = 1 to 1 timeframe like a plastic bottle going down the river always moving with same water. (input --- output)
- 1 to many = accrual = 1 to many time frame like a plastic bottle going down a river and it hits a lake. Even though water leaves the other end (outflow) it was not the water that came in. It also may not be perfectly balanced. This analogy could also include dam controlled releases, holding period, etc.
- Web – model different way to get at the data. Linear with permissions (date stamp).
- Start the focus here on the day to day – right in the center (bull’s eye). Daily business loop, weekly business loop, monthly, quarter, annually, etc. The further from the middle, the more likely it is a balance sheet item or action.
- Every demo: Basic, Intermediate, Advanced (detailed)
- Analogy for 1-many:
o Motorcycles: 1-1
o Cars: 1-many (small)
o Buses: 1-many (big)
o Transport trucks: 1-many-many (huge)
 
Click to view time photos.
AU 1322 Daily Tasks 3/31/2009   • Added a 50% off promotion code to the LTF website. Changed colors, added links, ads and deals page.
• Fixing a re-calc taxes section for specific units. Added new Federal tax tables to the application. These taxes were a mid-year stimulus related change.