ayanova/devdocs/todo.txt

@@ -109,6 +109,57 @@ CURRENTLY DOING:
 	
 	
 	next: Inventory is next, look at cases and decide what is first, lots to dig into here and many new features and changes
+
+
+Purchase order:
+	# QUESTION: STATUS - what is it really for and can it be simplified / more flexible as we are moving towards *less* tight control over inventory?
+	Do we even need it at all?
+
+	It *appears* that in fact there is only really two status of relevance Ordered or NotOrdered and that's only to lock the UI really, the rest is maybe just for user viewing?
+		yes, this is the case, nothing references status except for the UI to lock or unlock fields and in that case really only open or > than open are relevant for that
+		the poreceipt uses it to find things to receive against but now that is integrated into the PO no need for that anymore.  Hmmm...
+		The question is now does the user get some value from seeing the various status? and can that be solved by other means because the status induces fuckery for the user and the UI is uglified
+
+	The STATUS in v7 was used to:
+		drive the selection list for a po to be received (ordered not closed available)
+		lock the PO to prevent changes inappropriate to that PO Status:
+			OpenNotYetOrdered - new po, can edit anything
+			On order - can only change most header fields but not the items themselves from this status and higher as they are ordered and considered locked
+			Open partially recieved - can change nothing in any field but can click on "change closed status" to set it closed from menu 
+			closed fully received can change nothing
+			closed partially received can change nothing
+			closed nothing received can change nothing
+			And from the code notes of v7:
+				/// If a P.O. status is currently:
+				/// ClosedFullReceived - can not be changed to anything
+				/// Any status beyond OpenNotYetOrdered can not be 
+				/// changed back to OpenNotYetOrdered. I.E. once a P.O. is
+				/// OnOrder of some kind it can not be taken back to OpenNotYetOrdered      
+				/// This ensures Purchase orders follow standard business practices for inventory control.
+		Indicate to the user where it's at so they know if it needs attention or not
+
+	V8 status:
+		PO STATES
+		New can edit anything because it hasn't yet been ordered
+		Ordered
+			in v7 can not change the stuff ordered substantially because it's already been ordered
+			But then changes inevitably occur and there are some cases related to this, i.e. price changes, item is not available, item has changed to a different item entirely adn will be sent instead etc
+			so the user actually from time to time *will* need to change these items and there are cases asking to do this.
+		Closed / completed / done, no more anything to do with it, history, doesn't need to be in top of queue or dealt with anymore
+
+		PO ITEMS STATES
+		new, on order - can still be changed as it isn't affecting inventory
+		received - can not be changed, it has affected inventory, would need to back out to un-affect inventory to really work now
+			Also, if it was used on a workorder or something you really can't back out of that after the fact
+		
+		Maximum flexibility would be to allow any edit any time regardless and the only thing locked is things that are sold already or used on a workorder already which can't be reversed easily?
+		Though there is nothing to control here except inventory, the idea of locking the PO was just to ensure there was no changes from what was ordered to what will be received however that seems to be not reality and changes after order happen all the time
+
+
+#QUESTION: why do wokorders care about po's and vice versa, completely seperate operations / things?  Can they be completely disconnected?
+
+
+
 	
 EACH OBJECT DEV CYCLE:
 	FIRST