ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Sales >> The Search for Duplicate PO #'s in SO-A
http://www.istechforum.com/YaBB.pl?num=1066245977

Message started by kevind on 10/15/03 at 11:26:17

Title: The Search for Duplicate PO #'s in SO-A
Post by kevind on 10/15/03 at 11:26:17

I've run across a side effect of SO-A checking for duplicate PO Numbers.

If a relatively general use PO Number like "Literature" or "Exchange" is used, there is a significant delay (up to 5 to 30 seconds) while information from other sales orders spins by on the screen while checking for duplications.

My first thought is to make these informational type PO Numbers be more specific by including the Customer Code. For example "Exchange" would become "DS21 Exchange". This would work fine for us.
I would be interested in how others may have solved or will solve this problem.

A SO-A program problem that I think may need to be addresed is related to arrowing up though a Sales Order header. When You arrow up through the PO Field, the Search for a duplicate commences. If possible, it would be better to only do this when the PO field is entered or edited and the return or down arrow is pressed.

Title: Re: The Search for Duplicate PO #'s in SO-A
Post by David Waldmann on 10/15/03 at 11:38:52

I thought it only looked in SOs for that customer. In any event, I've never noticed any delay whatsoever while it looks for them. Maybe you have a lot of un-purged Closed SOs? I currently have about a thousand (I just went and counted them) open and, like I said, it takes no time whatsoever. OTOH, I would rather it was able to be turned off, as almost none of our customers use POs - so we're putting the person's name in, which is almost always the same, so we keep getting false positives.

Edit: I should say "about 1000 there". They're not all "Open"!!!

Title: Re: The Search for Duplicate PO #'s in SO-A
Post by kevind on 10/15/03 at 12:42:06

You are correct. However, it appears that the algorithm used to look for duplications is following the PO key in the BKARINV table.

The TAS application then needs to read each record with that matching PO to determine if there is a record where the Customer Code matches the customer code on the new order being entered. I just counted and I have 208 records in BKARINV that have the PO # "Literature". How many Orders out of the 1000 do you have that have an Identical PO?? It's these 208 records that it takes time to step through.

This is a perfectly acceptable way if you can't request a record directly from the Transactional engine that matches a given PO # and Customer Code. The Transactional API has a function (#36) that returns a record following the current index and apply a filtering condition. This forces the Transactional engine to only return relevent records. The TAS interface to the Transactional API must not give programers access to these Extended functions.

There are many reports in DBA that could benefit by being rewritten to step through a index instead of just reading the entire file and only keeping the records of interest.

Title: Re: The Search for Duplicate PO #'s in SO-A
Post by David Waldmann on 10/16/03 at 05:29:23

That makes a little more sense. We don't have any more than groups of 20 or so identical PO#s.