Multiple Location Inventory Design

Fri Mar 26 06:48:45 PDT 2010

So Walter,

Who has written an ERPS system in filePro?  Or are you just not really
answering his question and telling him to dump his 20 year legacy system. If
so, isn't that getting a little old?  Do you think we could just all agree
to drop that kind of answer when someone specifically asks for help writing
in filePro?  There are just the few of us who have this need seemingly, if
you don't, why not traffic in the ERP chat room of your choice instead?

I mean if you need to hear it or anyone needs to hear it yet again. I'll
state it once and all for the record... "Yes, if you want to go with
mainstream software and tools, don't stay modifying your filePro system, it
won't be profitable or useful in the long run."  Does that satisfy you. I
think everyone here knows that, will agree to it and could we please just be
done with those kinds of threads?  We buy it, you're right, we're all wrong
for keeping up systems that have worked for two and a half decades.  We
understand that you and the world has moved on... It does not behoove this
technical forum that deals with help on code basically... To once again hear
how it all can be done so much better with the latest ERP bla, bla has to
offer.  C'mon, if you have a reason to watch and contribute to the forum,
great, but if it is your idea to suggest people move off of filePro to
answer their question about how one should approach something in filePro...
It is entirely counter productive.  If you agree with me, put up some file
layouts, put up code like the others have done.  If you disagree... Well, I
would appreciate it if you answer this privately and don't turn this into
what you apparently wanted it to become with your first answer.

In the past 6 months I have had 3 serious, extended, multi-day discussions
with 3 serious, long-time users of filePro systems who are going through the
agonizing decisions to move away from it into the whole new world that's out
there... Or continue to use it and merge whatever they can (as time, money
and energy permits) with newer solutions. The definitive answer has been in
all 3 discussions with all 3 companies, yes, if you want a far reaching,
complete solution that will bring your company far into the future, move
away from filePro and make the commitment. In all 3 cases, (and they all
frequent this forum) it was determined that making such a commitment would
mean over a year of conversion/transfer/ramp-up time and low to middle 6
figures to finance it. At this point, 1 of the 3 companies chose that route.
The other two are still considering their options with one leaning heavily
toward keeping filePro, and one leaning slightly away from filePro.  In all
3 cases, however, should one them ask a specific question up here on "the
filePro mailing list" about how to accomplish something in filePro, I and
several others happily, have had the courtesy and time to give good answers.
You on the other hand, didn't have the time, and overlooked the courtesy of
allowing those who still use and want to use filePro to do so. Do you really
not think that's a fair way to approach this mailing list?

And in case anyone thinks I took one side or the other in the move away from
filePro discussions, I did not.  However, up here in this place, I would
continue to strongly suggest that filePro can still handle just about any
situation typical companies might need. Can it do it with mouse
accessibility and RDBMS implementation, no.  Is this a requirement? For
some, yes, for others, no... And that is why I, at least still work on and
for this forum?  Why do you?  To constantly enter into philosophical or even
hard-nosed discussions of the benefits of leaving filePro?  If so, I submit
that if people want that discussion they should get it from paid consultants
off line... Not in a decidedly technical pretty much code-based forum. Or,
at least in OT: marked threads.

I re-read this note and I know you're going to read it as heavy handed, but
when will it ever be time for people to just deal with the questions as they
are put and not include in the answer or have the whole answer be the
suggestion to use a different tool than filePro. That is simply not what
it's all about here, and you, 
Walter, certainly know that.

John Esak

> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] On Behalf Of Walter Vaughan
> Sent: Friday, March 26, 2010 6:29 AM
> To: filePro
> Subject: Re: Multiple Location Inventory Design
> 
> Top posted reply
> 
> You also might think about not re-inventing the wheel. ERP's with any 
> sort of WMS
> functionality handle this and way more with years of 
> debugging already done.
> This will only get more complex over time. You may owe it to your 
> customer to
> investigate solutions where the customizations are at the business 
> process level
> and not re-invent standard supply chain methods/systems.
> 
> 
> Craig Tooker wrote:
> 
> >On 3/25/10 17:37, Scott Walker wrote:
> >  
> >
> >>I have an order processing system.  Currently it only 
> handles inventory kept
> >>in one location.  Now a customer wants to start keeping inventory at
> >>multiple locations.  So the same part# could be in the 
> inventory at the main
> >>office and also at several branch offices.  I'm just 
> starting to think of
> >>the design of this.  Should I have a separate record in the 
> inventory file
> >>for each part#/location combination?  Should I use a 
> qualified file for each
> >>of the inventory of each location? (I don't use qualified 
> files for anything
> >>at the moment).   Of course, this design decision permeates itself
> >>throughout the system (ie.  Order Entry, Shipping, 
> Purchasing, etc).  Any
> >>design ideas or thoughts would be appreciated.
> >>   
> >>    
> >>
> >You should of course, keep the SKU related information 
> (everything but 
> >vendor, qtys and locations) in the inventory item master file.
> >
> >A detail level file for vendors that supply the item should 
> be kept to 
> >allow you to sell items from multiple vendors under one SKU 
> (in the case 
> >of commodity items or where you have multiple vendors 
> supplying the same 
> >item).  A vendor ID can then become part of an item 
> available level.  
> >Each vendor will have their own costing and delivery and 
> this will allow 
> >you keep them separate as layers of inventory (for purposes 
> of costing 
> >and implementing FIFO or LIFO).
> >
> >A detail level file that contains itemID, location, qty, 
> vendor, costing 
> >and date should be kept - again for purposes of costing and 
> FIFO/LIFO.  
> >Additionally you can then implement a stock locating system for 
> >efficient picking and correct allocation under the FIFO or 
> LIFO logic.  
> >This allows you to direct material handlers for picking items for 
> >invoicing or stacking items from orders.
> >
> >You could keep accumulators in the master record for total on-hand, 
> >available, allocated and on-order if you wish but it is not required 
> >(although it may make certain operations more efficient.
> >
> >Efficiency is also helped if you make that item detail level 
> layout the 
> >same for the PO detail (where you purchase the item) and 
> also on invoice 
> >detail (where you sell the items).  That will make the 
> management of the 
> >data straight forward and gives you the ability to make use 
> of COPY (and 
> >its friends).
> >
> >Craig Tooker
> >
> >
> >
> >_______________________________________________
> >Filepro-list mailing list
> >Filepro-list at lists.celestial.com
> >http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
> >
> >  
> >
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://mailman.celestial.com/pipermail/filepro-list/attachment
s/20100326/39a5a8a3/attachment.html 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 