From: Ricard A. <pak...@gm...> - 2013-10-19 03:51:01
|
Hi Jo: it's Ok for me to use config switches to allow / disallow new functionalities. Will be happy to test your upgraded scripts ;-) Regards, Ricard 2013/10/19 icedlava <ice...@gm...> > Hi Ricard, > > Thanks for your reply. I'm interested to have someone such as yourself > that uses the module, to provide this feedback. > > You raised some practical points that would be important to implement: > > * Modifying a stock request - certainly would be useful in practice to be > able to do this > > * Outstanding stock request listing/report - this is on my task list but > for a different purpose than yours of avoiding double input. I hadn't > thought of that, but certainly it's important. > > * The StockRequestFulfill is working but stock is only reduced from > sending location. There are no transactions currently for receiving side. > I can understand why this is so if this stock is only being distributed > to an internal department, rather than an actual stock holding location. If > it is a stock holding location such is in our use case, it does need the > supporting stock moves/incremented stock amounts done. > > If I did modify the existing script, perhaps there could be some option > switch here to turn on the appropriate transactions for the receiving > location ? Would anyone find this a problem? > > There are some usability issues at stock fulfil eg if there is more than > one outstanding request for a given location - it is very easy to > accidentally click and fulfil all outstanding requests on the screen rather > than just the one required. I'll try and address these if i work on this > specific script. > > After your feedback Ricard, I'm more hopeful of being able to modify the > existing script while leaving the default option to continue it to behave > as it is, with additional switch to turn on the extra functionality > required if receiving location needs underlying transactions for stock > handled as well - those that are not done at the moment in the current > script. > > Thank you and best regards! > > . > On 19/10/2013, at 11:45 AM, Ricard Andreu <pak...@gm...> wrote: > > Hi Jo: > > We are using this module and I agree with you, it's half done. It works in > a very basic way, and lacks some functionality, but it works. > > 1. Branch requests stock transfer from main warehouse to fulfill some > current requirements, or to fulfill requirements at a future date after planning. > It works in a basic way. No option to modify a stock request once > submitted. Also would be great a list of internal stock requested for that > location but still not delivered, to avoid double input. Users in the > destination location, now have no way to check if some intenal stock needs > have been requested or not, thus leading to double requests. > > 2. Stock transfer is approved by relevant department. Done and works OK > InternalStockRequestAuthorization.php. Also some user friendly > functionality would be great, as print outs, partial authoritations- > > 3. Stock is transferred out from main warehouse to branch, at the required > date which may be some months in future (or some other alternative such as > put on backorder and shipped when in stock, or outstanding cancelled). > Dispatch docket printed. Done at StockRequestFulfill. Nothing is printed > out > > 3. Branch is notified, and receives in stock on arrival. Transfer note > generated and used to check for received items and head branch notified if > there are discrepancies. Not done at all... would be nice. > > 4. Usual stock moves, stock quantities at location and dispatch records > are updated in relevant tables at dispatch and receipt (or GL records if > stock GL on). Not sure if it's done. We use it only for consumable stock > (business card, cleaning materials, shopping bags, etc) and don't control > stock outside main location, so never checked it out, but I guess it's > somehow done, as stock at main location gets properly updated. > > 4. A report of outstanding stock transfer requests for a given branch > should be provided when required. Not done yet,and would minimize current > human errors, as all works with screen printing. > > Note that I have added ability to print stock dispatch docket and transfer > note at any time from an amended Inventory -> Stock Transfer Note report > option to solve some of this issue. > > Hope it helps > > Regards, > Ricard > > > 2013/10/18 icedlava <ice...@gm...> > >> I have been looking at Internal Stock Requests to see if it can be used >> in a specific client case. >> >> I am unsure if the current Internal Stock Request script is meant to be >> finished or still requires some added functionality. Unfortunately it >> cannot be used for our specific problem as it currently is coded. >> >> >From what I can see: >> >> 1. Stock request is made >> >> 2. Stock request is approved >> >> 3. Stock request is fulfilled - but at this point script seems only half >> done. >> a. Stock movement table is updated for RequestFrom location, >> b. stock location qty table is updated for Request From location >> (reducing stock), >> c. and the stock request table(s) are updated to reflect dispatched goods. >> >> There seems : >> - no way to print a dispatch docket (and each item is held with different >> reference in stock moves table) >> - no way to receive in stock at receiving branch >> - no stock in transfer state prior to receiving >> >> I thought that as a dispatch, this transaction should also be treated >> like any other stock transfer and intergrated more fully with existing >> functionality eg: >> - be inserted with a reference stock transfer id in the stock transfer >> table >> - a stock transfer docket can be produced >> - be able to be received in at receiving branch >> - stock transfer id can be viewed (similar to other 'normal' transfers) >> - stock moves and location quantities are updated accordingly >> >> However, perhaps i misinterpreted or do no understand the objective of >> this script. >> >> If this is something that has yet to be complete in internal stock >> transfer, I have to code this in any case, and could add it to the >> existing code. (As well as report of outstanding transfers at any specific >> time). In this case, I would appreciate any feedback to considerations that >> I should take to ensure maintaining of compatibility with existing possible >> scenarios. >> >> If the internal stock transfer function is complete - then unfortunately >> we cannot use it, and must look to another solution, or code it in custom >> branch. >> >> If there is anyone with some insight into the Internal Stock Request and >> possible solution to this problem, your feedback would be much appreciated. >> The general requirements we need to fulfill are outlined below. >> >> Cheers, >> >> >> Posted to forum and dev list >> >> --------------- >> We have a requirement for the following: >> >> 1. Branch requests stock transfer from main warehouse to fulfill some >> current requirements, or to fulfill requirements at a future date after >> planning >> >> 2. Stock transfer is approved by relevant department >> >> 3. Stock is transferred out from main warehouse to branch, at the >> required date which may be some months in future (or some other >> alternative such as put on backorder and shipped when in stock, or >> outstanding cancelled). Dispatch docket printed. >> >> 3. Branch is notified, and receives in stock on arrival. Transfer note >> generated and used to check for received items and head branch notified if >> there are discrepancies. >> >> 4. Usual stock moves, stock quantities at location and dispatch records >> are updated in relevant tables at dispatch and receipt (or GL records if >> stock GL on). >> >> 4. A report of outstanding stock transfer requests for a given branch >> should be provided when required. >> >> Note that I have added ability to print stock dispatch docket and >> transfer note at any time from an amended Inventory -> Stock Transfer Note >> report option to solve some of this issue. >> >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Web-erp-developers mailing list >> Web...@li... >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk_______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > |