assembly => [ stages => [ sops => [ product_ids => [ ] entry_code => only one entry code, most_probable_exit_code => to help the scheduler decide which exit code to pick. product_arrays => [ { time_added : product_ids_added : [], product_ids_removed : [] } ], steps => [ step => { checked_in : { time : location : actor : }, started : { time : location : actor : }, ended : { time : location : actor : }, ## or should that be called on update? performable_product_ids : [], exit_code : can output an exit code, if no exit code, then goes to next step, last step has to have an exit code. expected_duration: in mins requirements: [ requirement: { state_definition: { }, outputs: [ { } ], requirement_reference_id : } ], instructions: [ ## all instructions have to be given considering multiple numbers of the { pool requirement 1 pool requirement 2. mix } ], process_step : function(args(hash with any varibles needed to do this step, or the generic hash of variables passed in.)) -> basically just compare states for every single requirement, vis-a-vis its previous requirement id. what if we want to do something with some other variables? } ] ] ] ] ------------------------------------------------------------ cart_items => -------------------------------------------------------------- transit_object => keeps a track of all the states 1> clone the assembly -> if its not already cloned -> how to decide if to clone a new assembly ? create the concept of assembly validity, wherein the assembly is cloned only if validity of previous assembly has expired. A function determines the validity of the assembly. 2> arguments : {:cart_item_ids => [], assembly_id => }, method_to_call : get_applicable_sops, object_class: assembly., object_id : from step(1) for each sop, generated from step 2 - push the next event. 3> arguments : {assembly_id => , :cart_item_ids => []}, method_to_call : create_order, object_class : sop, object_id : sop_id. = here ensure that the cart items combination in the order is searched for atomically while creating. = and the after create callback will be managed by event logic. = so now let me first focus on order object - its structure and creation logic. = schedules also should be created inside orders only. = or schedule references at least. in the on_create callback : 1. do i have what i need ? -> if this is the first order on this sop ? -> check what consumables will be needed, (not dependent requirements), and send the events to mark for product. -> this is not the first order on this sop ? -> all schedules on this sop are either finished or failed -> dont do anything. -> some schedules are still to be done -> dont check anything, wait for these to be executed. 4> arguments {sop_id => whatever, assembly_id => whatever, }, object_class => product, object_id => consumable_id_to_be_marked_for_the_given_sop, method_to_call : mark_for_sop. When an sop is marked as complete, then an event should be pushed to schedule it. 5> arguments {assembly_id => whatever}, object_class => sop, object_id => sop_id, method_to_call : schedule now while executing a sop, we consider the additional orders as well, and find a) we don't have everything we need. -> create an event : 6> arguments {assembly_id => whatever}, object_class => order, object_id => order which cannot be processed, method_to_call => evaluate_from_beginning. In this method -> take each sop to which this order was added from the beginning -> call "do_we_have_everything_we_need" => if yes, go to next method, otherwise go to last successfull one, and from there, till the very end -> do the same process as from 3 onwards, except in 3 don't create the order, just do the callback,and when you create the schedule events, make sure the schedule is added, but only for that order. ** now come the eventualities of adding a product later on. so suppose a product is added later, what is different. the idea was that we add the order to all applicable sop's after_create consumables would be checked. ** and about the map. while doing this a map will have to maintained, for every product, whether or not an sop is ever going to be hit which has this product id applicable to it?, in the if the answer is no for any product -> then an event will have to pushed, which will do the flow step defined below. if the answer is yes, we can wait for that sop to be triggered to see if flow step needs to be done or not. Flow: start from the first sop that is applicable to the product. are the sample requirements satisfied ? - no -> the previous sop -> go there and schedule from there, go there and schedule means what? - we need to schedule every sop thereafter. - to do this, we need to add a set of events. - but when this sop is added, it has to have a scheduling mechanism which works a bit differently. - sop will also have a set of schedules - basically - this comes down to sop sructure. - yes -> go to next sop. - sop { "orders" => [ {}, {}, {} ], "schedules" => [ {}, { "just adding the order is ok.", "but thereafter but then, the sample requirements will not be satisfied, so " }, { "in case a schedule has an order id, then only process that order, if it doesn;t have an order " } ] } - how to earmark sample for a sop even before that sop has been done? - this is am important point, and just adding the orders is not enough, we have to check if there is enough sample. but what if all the sop's cant be done, due to a sample constraint somewhere down the line. when adding order to sop -> sample has to be checked, it is a part of add order. what about reserving samples on adding. there are two reasons why it could not be done : 1. there was a prexistent sample shortage. -after adding all the orders , we start scheduling, so before scheduling even one, we have to make sure we have the sample requirements, and segregate them at that step itself. so how will that be done, evented. -> lets say after adding order to sop -> it creates a event, that says, decrement, n samples from the product, and mark them for this particular sop. and it does that for every single sop, order pair. now that part is subsequently run, and only after that, is the scheduling phase going to begin. so suppose we 2. the shortage happened dynamically. - so basically order has to be 4> suppose that sop status is : - so i have an array of applicable sop's with the product ids's to which they are applicable. - now i want to know whethere i need to branch from a particular sop - which could be the very beginning or anywhere thereof. - it just adds the orders - now the next job is also added simultaneously - the initial state of the order is just nothing. - now what will it do? - start from the back ? - let's say a particular sop is running. - it picks up all the orders, and checks sample requirements , if they don't get satisfied, it will run upto whatever it ould do. - the first time an order is picked up, and not satisifed, it should then be attempted in a branch concept. - so assume an order sample requirements are not satisfied. - in that case, create an event, where -> it is going to search all the applicable prior sops, for a point where the sample requirements are applicable, and schedule it from there onwards. - so it will have to go over each sop, till the point where it is not applicable and consider the previous one. - scheduling events are then created for making the schedules on those sop's for that order. - finally, when the order is scheduled, at that time the product amounts are minused. - what else remains here ? - product provisioning. - how to mark sop as done, step as done, - how to add images -------------------------------------------------------------- clones assembly => search for those sops which are applicable to the product_ids => now build an order object => now create it into the first applicable sop => validates that the sop can process it => calls method process_step => calls sufficient? => on each requirement => returns the consumables to be created with the order, for each requirement. => those consumables are added to the order at creation, and product stocks are derived from that. ## can we know if we can add it to all the sops at the same time, i mean update all the sop's at the same time? ## but if we reach a sop where it is not sufficient, then we will have to have a staged, withdrawal, where that order will not be marked for acceptance, if a sop somewhere down the line could not be handled. ## so after order is added to sop -> what is its state ? ## it will check the transit object and only then schedule it or take it for scheduling. ## now how to have it layered? ## so how to create and update the product stocks. ## basically if the product is consumed, in one place, and ## created in another, then it will be difficult. so suppose we create thousands of products. and then we create a consumable before order is added to sop -> we have to check for each step if it can be processed, and in doing that so if its applicable -> create it. then check if the requirements are there -> suppose a requirement is satisfied -> that means we will have to in one operation create all the consumables, inside the sop. so we can have two states -> 1. inside the status object -> for each step. 1. gather consumables 2. decrementing product counts (here we should store the product ids that need to be decremented, and by how much.) 3. creating consumables. this is the only way to do all this. so basically on adding an order what series of steps have to be followed? 1.d 2.b12 3.thyroid 4.axilla 5.edema 6.myasthenia 7.claudication 8.appendix - leucocytosis 9.gall bladder - shoulder_tip pain / clinical exam -> liver functions. 10.cholesterol - signs / symptoms / clinical tests 11.cerebellar function ? copper ? 12.iron - koilonychia for spoon nails. ( can be done ) -------------------------- lft kft iron -- how to do a particular def only at a particular time. -- suppose you want to do a qc only on monday's? -- that part is done by a scheduler, to trigger the creation of orders. -- while scheduling the sop the most important points are: 1. it has to have certain requirements -> like when was the previous sop for the same orders ending -> that will give the ability to know when to set this sop for scheduling. 2. these will happen in a certain order. 3. so how to know that schedule? 4. we need something called get_previous_sop. 5. that will tell us the previous sop but sometimes we have a situation where the sop's dont happen at the same time 6. in that case how will you deal with it? eg: stool and blood both cart items are applicable to the delivery sop ,and pickup sop. but from thereafter , we are fucked. so inside schedule , we will have to know so the sop;s will have certain conditions for each and every product, which define about that. or will it be defined inside the product? no it will be inside the sop. so for example inside that sop we will have - product_id => conditions for scheduling. problem is that if you change somthing, the shit will fly. this is fine. so we need another embedded document -> product_id => whatever conditions_for_sop => { time_information : { days_of_week : days_of_month : days_of_year : dates : time_of_day : (always a range) zone_of_day : (morning,afternoon,evening) } locations : location_ids scheduled_after : sop_address (stage_index,sop_index) } these sop conditions have to be evaluated while scheduling it. they have to be evaluated independently for each order. so a schedule will so we have order already it is inside sop. it has a number of cart_items. now we have to do schedule, so what will it do? so sop will have another embedded object -> schedule_information => { product_id => schedule_information => { time_conditions : { }, location_conditions : { }, do_after_sop_conditions : { applicable : true/false, time_conditions : { }, location_conditions : { } }, machines : [ { category : xyz, id : if specified, use it, } ] } } so it will search for these machines, there also we can give a location id. if more than one location id is given, then nearest location is considered. for machine also can it be done like that? suppose you need 4 machines and 2 workers at various points in this sop. how will you schedule it? suppose you need the worker from step x -> y. and so on and so forth. so this whole thing will have to be done one step at a time. suppose a machine is needed in n steps. then we keep the machine in all those steps. doesn't this fit more with requirements.? where we go to mark requirements, these are also requirements. i think all this has to happen at the same time. for a particular step, whatever are the requirements, should only be marked, after the scheduling is done. we also will have to go through an unmark phase. for eg if the next machine is not available till a time expires, then how does this work? suppose you want to mark do requirement scheduling its like saying, schedule it, and mark the requirements. when the schedule is made, suppose something is not there or it fails, that goes into another league of shit. so we schedule one step at a time ? => yes. what about nested scheduling ? so we can carry forward? what machine needed, needed, needed, needed, okay now schedule. you can't schdule half, you can only do pessimistic scheduling you iterate each step, see if its marked for a schedulable requirement, and then see if that requirement is maintained, and in that case, you collect the endpoint so you get a duration. and at that point, you do the scheduling, now at any point if a particular schedule could not be fulfilled, then what to do, or a requirement could not be marked then what to do ? we know the schedule requirements. basically the schedulable requirements have to be synchronously scheduled. so schedule has three parts : 1. assembly the schedulable requirements. 2. query for all of them, and get best time slots. 3. do a find and update for the combined schedule document. the or clause has that as the upsert (i.e id of the present sop.) so for this i need a schedule document, and i need to make this concept of scheduled requirements, and exclude those from mark_requirement.