ayanova/devdocs/todo.txt

@@ -24,6 +24,11 @@ todo: PickList controller route, how can I document the params into the api expl
 	do I need a reference link to the class?
 	or can I comment in the class and have it extrapolated?
 
+todo: going to need some default views for certain lists that come with AyaNova automatically (even if migrating)
+	some lists may need a list of all but also a list of all relevant items only (part inventory?)
+	Views that supply common tasks or functionality that was in v7 in another way
+	perhaps need a case to consolidate that under or maybe add the views during development?
+
 
 todo: customer popup notes need to pop pop pop, forgot to code for that before	
 	It's been requested for a couple of other places as well so I need a re-usable solution for this
@@ -130,14 +135,40 @@ todo: server boot up message should show the port it's listening on if possible
 
 
 
-CURRENTLY DOING: 	PartByWarehouseInventory - startup, read cases and go from there, mirror servicebank technique for inventorycontrol
+CURRENTLY DOING: 	PartByWarehouseInventory 
+
+	Past issues with this are that it can go out of whack and be hard to track down what happened in case of a bug or something
+	there were lots of bugs in different areas that allowed weird shit to happen like being able to enter a negative on a PO for quantity
+		Those bugs were enabled by the inventory being a bit loosey goosey and allowing stuff like that to happen
+	A ledger can also be the adjustment feature as well, it's one and the same so you can directly add a manual record to the ledger as easily 
+	To get inventory stock picking list you just pull the most recent unique part/warehouse combo values from the ledger that have non-zero balances
+	if a source object is deleted the ledger is kept but the matching ID is set to zero (or do we just accept they are not existant?  I mean, does it matter in any real sense?)
+		the description will have the source anyway i.e. "LT:Workorder 25" which should display correctly
+		actually, if the TYPE is kept then that's all that matters and description shoudl just contain the Name or Serial field value
+		maybe should redundently store the userId as well?  but then some users are not necessarily tied to the operation
+
+If it was a ledger:
+	PartInventory
+		entrydate
+		lastentrydate
+		sourceid
+		sourcetype
+		description (permanent snapshot of where it came from in case of delete of source object, which is allowed and doesn't affect this just like history )
+		partid
+		warehouseid
+		quantity
+		balance
+		lastbalance
 
 
 Inventory related objects that need to be ported:
  XPart
  XPartSerial
  XPartWarehouse
-PartByWarehouseInventory
+PartInventory (was "PartByWarehouseInventory")
+	transformed into a inventory transaction ledger as per case 3847
+PartRestock
+	contains partid/warehouseid/minimumstock level
 PartInventoryAdjustment
  XPartAssembly