From f15b4fb215aecc328edf8f32e7042b09b33df1ee Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Mon, 15 Feb 2021 23:30:37 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 73 +--------------------------------------- 1 file changed, 1 insertion(+), 72 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 43b25e98..f134f2b5 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -86,7 +86,7 @@ todo: how to add locale keys in future after release without erasing all data? -CURRENTLY DOING: cleanup +CURRENTLY DOING: PurchaseOrder @@ -106,77 +106,6 @@ WorkorderItemPartRequest - -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 - - WHAT IF: status was entirely user controlled and they can set it to what they want and we never lock the UI for it? it's just a flag for convenience - WHAT IF: we also add a Closed / Open button which prevents casual editing? - WHAT IF: the po list was based off a view and the view calculated if a po should be considered fully received or not and flagged that in the UI list - WHAT IF: Ordered or not Ordered as a separate checkbox they select that they can set at any time? - WHAT IF: Fully received is calculated from ordered-received from all line items in list view query of PO's? - WHAT IF: any changes to line items taht are tied to part request would just reverse or fixup whatever they type in if not received yet - - - #QUESTION: why do wokorders care about po's and vice versa, completely seperate operations / things? Can they be completely disconnected? - PO / REQUEST / WO links - Do we need these? Does the user ever really need to drill into the workorder from teh PO? Vice versa? Doesn't this only matter up until it's fulfilled on either side one way or another? - The links mean we have stickiness issues with just allowing users to edit things at will so detracts from flexibility desired. - - -PART REQUESTS: - # QUESTION: can it be untied from po once it's fulfilled? - - -#TENTATIVE CHANGE IDEAS FOR INVENTORY -PO STATUS - Keep status but PO itself and it's items are never locked until received. If the status has been ordered then maybe a warning on save if changes made to anything that used to be locked in v7 "This po has been ordered, are you sure?" - except, why have a status at all then other than for user to see it? Maybe that's the point and in that case just let the user set the status to whatever they want with a select control - If user wants to delete or change an item that was received, since it's in it's own UI form it will prompt "Are you sure you want to reverse this inventory transaction?" and then adjust - - ------------------------------------------