Hi,
May I ask did you all face a problem of SLOW PROCESSING when do AP matching ( purchase order matching)?

The session that involved:

1. tfacp1230s000
2. tfacp1130s000
3. tfacp1131s000
4. tfacp1140s000


Especially when come to tfacp1140s000,It take very long time to complete the process.
So,if any of you face the same problem as me,then how you all solve it?
May I know which part of the script have been modify??

thanks alot.

Hi,

Of course you can look if the software can be updated.
Else I wonder how big is your tdpur040/41/45 tables.
These tables concers the purchase orders and the receipts.
If there are lots of orders in there then during the matching the invoice the system goes tru these tables.
Check if you have a lot of orders over there. You might think of archiving the purchase order data. But before that make sure you can first reconsile your GRNI Accounts (Goods Received Not Invoiced)

Regards
Otto

Otto

May I ask you what is this meant (make sure you can first reconsile your GRNI Accounts (Goods Received Not Invoiced)) ?
and how to do it?

actually myself is totally new to finance.

I check my program script ,it is not the latest version.
so I can directly update it?where to get the latest version?
actually I try to modify the script,but after change the script,the processing never improve.
Please guide me.Thanks alot.

We find AP matching extremely slow too. If its a simple one invice = one PO match, then its fine, but if its an invoice for multiple PO's, the system takes FOREVER to call up all PO's for that supplier. Yes we have a big tdpur045 table, but will always have this. We've thought of using one common packing slip number for all PO receipts on one supplier invoice, then enter that packing slip number in tfacp1110s000. This works and calls up only those PO receipts for the invoice, but is still very slow, and I mean approx 10 minutes of hourglass before screen changes. I think probably an index using packing slip would help.
Has anyone put in an enhancement request for performance improvement for AP matching? I certainly feel its necessary.

Slow performance: Try reorganizing the tables to re-optimize the indices. Also: run the session with the TT_SQL_TRACE=20240 option to learn what queries do take too long. Then check and maybe also repair/reorganize those tables as well.

hp,

Can you please fill up your BaaN/OS/Database info in your profile?

If you are on Oracle, you can consider to do a analyze on the tables to update the statistics.

Or
use -- -set DBSLOG=value (or added values) to get debug info from the online processing of the database driver:

value description
0000001 data dict. info of tables
0000002 query info (sql level 1)
0000004 query info (sql level 2)
0000010 row action info
0000020 table action info
0000040 transaction info
0000100 dbms input/output data (sql level 2)
0000200 admin file info (sql drivers)
0000400 dbms sql statements
0001000 general debug statements
0002000 query processing info
0004000 data buffering info (communication)

Dear NPRao

My Baan version is Baaniv ( b40c.043)
,and we are in informix database ,and OS : unix.

Sorry,me still new in Baan.
so,I really can't get how to do this : set DBSLOG=value



Dear OmeLuuk
what is TT_SQL_TRACE=20240 ???
where to run it???

hp,

Those options are used in the BW profile. If you are on the BaaN-4 series and without the BW interface, I am not sure how do it on the ASCII terminals.

Maybe, OmeLuuk or other BaaN-4 guys will help you out.

hp,

This is identical to the problem we had in tfacp1110s000. We did put an enchancement request into Baan in September 1999 but never recieved a response.

We had response times of about 1 min on the packing slip field and put up with it for far too long. The archiving of tdpur045 had no real effect.

The problem was solved by adding an index for the following onto tdpur045;

dino,matc,comp,cmbd

Because of the way the query is written it automatically picks up the new index.

Following this change the session went straight through the packing slip field and the response time is now less than five seconds and we have never had any further issues with this session.

Good luck

Neal Matthews
Intier Automotive - IT Support Analyst

Neal is right too... sometimes the way you code also result in different Oracle indexes/hints being picked up.

I dont know which particular Drivers (level-1/2) you are using.

But with the latest porting sets you can explicity specify more options in your SQL statements and analyze the performance impacts.

Please refer to the Hint types (http://www.baanboard.com/programmers_manual_baanerp_help_functions_query_hints_hint_types)

Neal Matthews

Morning.

You meant add in a new index which contain (dino,matc,comp,cmbd) in table tdpur045 ??

No need to modify the script at all???



Thanks alot.

No need to touch the script at all.

We do not have a developers licence but we were given a temporary licence so that we could add this index ourselves.

Index number 9 is now ;

dino,matc,comp,cmbd

and the session works perfectly.

Regards
Neal

hpng98: what is TT_SQL_TRACE=20240 ???
where to run it???TT_SQL_TRACE is a logging of the traffic between the application and the database driver. The value 20240 means:
000040 = Show queries wih their QID
000200 = Show query exec. times
020000 = Show all full table scans
+ =
020240

You run this by putting this line on the Configuration Screen of bw.exe in the "Command" box:
-- -set TT_SQL_TRACE=20240 -keeplog -logfile ttsqltrace.txt
This will make a file of your Baan session with logging of the queries that are performed, what exec times are spent, if and which database scans have been done over an entire table.

If you use ba6.1 to start Baan, you can use the same line after your call to ba6.1:
ba6.1 -- -set TT_SQL_TRACE=20240 -keeplog -logfile ttsqltrace.txt