This commit is contained in:
@@ -101,13 +101,18 @@ todo: PLANNING workorder data and class and route structure:
|
||||
Need to go over all wo features and factor them into this decision properly
|
||||
The whole idea of a completed section of a wo and stuff, is that dropped due to TTM or still viable?
|
||||
maybe can pick out the best new features of that which can be integrated into existing design rather than re-inventing the wheel
|
||||
Here is an overview: https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3412
|
||||
How best to be able to service LoanUnits on a workorder?
|
||||
Just make them Units with extra properties exposed if type of loaner?
|
||||
This seems simplest, but what will it effect?
|
||||
Hard to make them serviceable if they are an alternate table of source for what's being repaired as that breaks a lot of other code or adds exceptions
|
||||
Customer is then who exactly because it's fundamental to a lot of wo functionality?
|
||||
from a biz perspective isn't it like you are your own customer when you service your own equipment that you loan out?
|
||||
|
||||
Does Serial field need to be numeric, could it be text instead?
|
||||
prompted by case 3428 saying that it's hard to deal with constant conversion to text for UI etc
|
||||
plus, I'm thinking it opens door to textual scheme like appending -A or whatever to a wo.
|
||||
or, is that a display issue?
|
||||
Calling something "serial" implies it's unique but it isn't, maybe I should call it "number" instead or "ID" or something?
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user