Multiple Location Inventory Design

Fri Mar 26 07:48:12 PDT 2010

John,

I wish everyone felt the way you do. filePro has its place. I too considered 
leaving but have not - yet!As long as I can do some of the 21st century 
things that has to be done. For example, we need to be able to automate a 
process which logs on to a website (not ftp). Click on the correct parts of 
the site, perhaps answer some questions and either upload or download a 
file.

If we can't do these types of things easily we may have to leave filepro. I 
understand that this involves communication with the outside world which 
should not affect keeping filepro.

My other concern is as we get older that people like you will eventually 
lose interest in the filepro community and filepro will fade away. Then, 
instead of having built something of value over all these years, it will be 
lost and I have to reinvent the wheel with a new platform/package.

As you may remember, we had a one day meeting which the Hoover's were kind 
enough to host. I still inquire periodically what the status is of some of 
our suggested initiatives but that seems to have gone nowhere.

Please stay involved. Your involvement, and others, has always encouraged me 
to try new things with filepro as I am sure it has for others.

Dennis Malen
516.479.5912
----- Original Message ----- 
From: "John Esak" <john at valar.com>
To: "'filePro'" <filepro-list at lists.celestial.com>
Sent: Friday, March 26, 2010 9:48 AM
Subject: RE: Multiple Location Inventory Design

>
> 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
>>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list 