Menu
▾
▴
Re: [WebERP-developers] Internal Stock Request - is this functionality complete?
|
From: Phil D. <ph...@lo...> - 2013-10-19 04:22:17
|
I am not close enough to this to be sure but i am wondering if your mods which all sound very reasonable should just be part of the functionality and i cant see why any one would turn it off with a config switch. Possibly no config switch is needed -- Phil Daintree +64(0)275 567890 Skype: daintree icedlava <ice...@gm...> wrote: >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 |
