ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Items >> Rework locations
http://www.istechforum.com/YaBB.pl?num=1219935528

Message started by lesleys on 08/28/08 at 07:58:47

Title: Rework locations
Post by lesleys on 08/28/08 at 07:58:47

We would like to seperate returns from customers and have it show in two locations. The only QC receipt feature I found is for receiving in p.o.'s from vendors.
When doing a credit for the customer it puts the quanity back on hand. This gives other employees the perception that we have good parts to sell. We would like to seperate until they are reworked and considered good. Is there any way to accomplish this?

Title: Re: Rework locations
Post by GasGiant on 08/28/08 at 09:09:16

If you are using Evo then you could use the new RMA module for this. It was designed to keep returns and repairs separate until they are "dispositioned" or returned to customers.

If you are a DBA user you could create an RE location where you process all returns and repairs. We bring all returns into our RE location and turn them over to QC. If they determine that the items can be returned to stock then they will transfer them into our standard inventory location. The RE location should be set as a non-stock location in IN-L-B under Loc Type

Title: Re: Rework locations
Post by Lynn_Pantic on 08/29/08 at 19:30:50

Actually, the RMA module is available for both DBA Classic and Evo, if the IS Tech updates are up to date. You can also establish a segregated Location for the RMA/Repairs.

Title: Re: Rework locations
Post by GasGiant on 08/29/08 at 19:43:55

Right. I keep forgetting that you are still adding new features to both. :)

Title: Re: Rework locations
Post by kkmfg on 09/02/08 at 11:26:16

GasGiant wrote:

Right. I keep forgetting that you are still adding new features to both. :)

Which, more than a year back, the users voted that they didn't want. http://www.istechforum.com/YaBB.pl?num=1173301597

So, I hope that adding features to Classic has come to an end.

Title: Re: Rework locations
Post by GasGiant on 09/02/08 at 11:52:12

More update subscribers would need to migrate to Evo~ERP so that there is a clear majority moved away from DBA. With the amount of resistance still bubbling up from users, I'm sure progress is slow. Yes, going ahead with the cut may be the best method of encouraging customers to switch, but it is also sure to cause those who will not switch to drop their update subscription... thus cutting off part of the revenue stream being used to fund progress. Vicious.

Title: Re: Rework locations
Post by NovaZyg on 09/02/08 at 12:46:11

Welcome to my world....

I would love to drop new features to classic. (then only do bug fixes) but you can't bite the hand that feeds you.
and there are too many users that have Classic or a mixed system of Classic and Evo that we just can't drop it.

So for now we keep doing small things for Classic, but my focus is more on Evo.

This said, I don't ever see an end to the Classic product, but maybe someday no more new stuff, and bug fixes only...

Title: Re: Rework locations
Post by kkmfg on 09/03/08 at 04:29:52

GasGiant wrote:

Of course, too thoroughly diluting resources is a good way to send a lot more people packing. Evo would have a lot more latitude if Classic support could be dropped. Data could be better normalized, things encrypted, tables rearranged, no need to keep backward compatibility. I mean... for crying out loud TAS3.1 is a DOS PROGRAM. DOS.... you know, that OS we used to run back before Windows 95? (Yes, I know Win95 and 98 bootstrapped from DOS but they effectively wiped it out once they got going.) DOS hasn't been really popular since the mid 90's. Now it's the late 2000's. I've converted most all of my old VB6 apps to .NET and VB6 is a LOT newer than Tas3.1.

To me it's really insane that some companies are still holding out on classic. The new Evo programs can be set to look like classic and, for the most part, they work just fine. If a company already has a subscription then there really is currently no reason to not update. Unless, of course, these companies are running DBA Classic on an Atari or an etch-a-sketch. And, I should say... that they have no reason to update after the update has been out a few weeks. Like basically every other software program on the market you want to be careful not to update too early... I've found that out the hard way. And I still do it... Some people never learn... :(

If it isn't clear, I think that DBA Classic holdouts are a major drag on the Evo community. If anything, they are what is holding DBA back.

So, ISTech might not bite the hand that feeds (even if it is feeding them with one hand while the other hand has a chokehold) but I'm certainly more than happy to highlight the choking *other* hand of the feeder.

Title: Re: Rework locations
Post by GasGiant on 09/03/08 at 05:13:34

We moved to Evo fairly early and I am always updating something around here, but we still have a few DOS programs running here and there. We have an old data acquisition program collecting data in our electrode etching process. It uses Dbase III+, FoxBase, and Access (yes, all three) to collect simple data and convert it into two different forms of output (printed and plotted). It works about 99.7% of the time and I don't really want to put in the effort to change it. Eventually the equipment that is profiling our electrodes will die, or else we'll find a better process, and a whole new recording system will be needed to support it.

A number of DBA users feel about Classic the way I feel about the profiling software: it works, it's low maintenance, so we'll just leave it alone until it starts to die, then it will be time to find something new. I'm not saying that they are right or wrong, but they may be making their decisions (or no decisions) on a faulty understanding of where Evo~ERP is today. Anyone who first tried Evo when we did may have a poor view of it. Unfortunate, but true, first impressions are lasting and it is much harder to make the sale later if the product was lackluster on the first test drive. You can tell people that, "This is not your father's Oldsmobile", but that might not be enough. Somebody has to prove it to them, and bring them along at a "safe" pace.

On the other hand, IS Tech stands to lose customers (and potential customers) by not moving ahead steadily. I don't envy Lynn and Allen as they walk this tightrope. They can't be all things to all people, and they aren't likely to find much venture capital in such a small niche. They have to make it on their wits and manage their risk carefully. Their progress may seem slow in today's rapidly advancing technology field, but I trust that they are advancing as quickly as prudence will allow.

Of course, that doesn't mean we can't "encourage" progress ;)

Title: Re: Rework locations
Post by kkmfg on 09/03/08 at 06:00:01

Yeah, I understand the draw to not fix what's not broke. But, I still remember DBA Classic. Believe me, it does NOT fit my description of "not broke." Quite frankly I have no idea why we switched to it in the first place (and I was here and involved in the decision to do so.) EvoERP is coming along and getting better all of the time. I just hate to see progress get hampered by trying to support Classic. In my opinion Classic was always pretty sub optimal but Evo is starting to look as if there is a diamond in there somewhere.

All we need now is a little more work to chip it out of there: TRANSACTIONS. WE NEED TRANSACTIONS. Don't pass go, don't collect $200, just make the whole thing transaction aware. Bonus points if a given transaction can be fully backed out in case of trouble. This would require storing transaction ID's on every record or otherwise having a perfect log. But there are some times when either the software blows chunks or one of our brains does. And then we'd really like an UNDO button.