Hi,

I developed importing functionality (purchase invoices) using a little bit AFS (a dummy query with a report containing the importing functionality). To make it really work I had to do some hardcoded table updates. It all worked nicely in sp11. Input was read from ascii files.

After upgrading to sp18 I stumbled on the two following -silly- problems:

1. In case the ascii file contains two invoices -in some cases- the first document is processed oke and the first afs call related to the processing of the second document will result in a hang situation (the report script is stuck; examining the process list of the bshell reveals nothin unusual (no sessions are waiting for input etcetera)).
Notes:
- 'in some cases': I know what input to provide to reproduce the hang situation; in other cases the report script will process and end without any problems.
- when I remove the first document from the ascii file and restart the report the second document will be processed correctly. I.e. there's no functional problem.

2. 'In some cases' the ostpapiserv program will not end. I know what data to provide to reproduce this situation. Note that the ostpapiserver didn't exist in sp11. In case the apiserv program ends oke I can see the following message in the afs.log: 18dll->serv (afsscript: exit(18)). In case the ostpapiserv doen't end this message wil not appear.

Anyone having a suggestion?

Henny

We had several problems with SP18. We did get some new tools and stpapi patches from Baan. On top of that with SP18 SSA had started incorporating their warehouse product. This caused us a lot of problems in the receiving area. Baan fixed the code for the sessions I identified - most of it had to do with lot controlled items. I also had to redesign my piece to actually get lot controlled items to work again. I would report this to Baan as soon as possible. Currently we are testing service pack 19.

If you have source you might be able to trace the new problem.

Hi Mark,

For your information: I installed the latest version (solution 205876). So far this doesn't seem to make any difference.

Henny

What porting set - we use 6.1c.07.04. It seems to me someone posted something in this forum about problems with a porting set. No promises this would solve the problem - over the years it seems like something different with each SP, one reason I recommend contacting SSA.

Hi Mark,

I already posted a call at SSA describing my problem. So far I didn't receive any answer. The portingset should be oke I guess:

Portingset : 6.1c.07.06
Port no. : PA.2638
Date : Tue Nov 30 16:39:29 MET 2004
Uname : HP-UX torka B.11.00 A 9000/861 2016171322 two-user license
Machine-id : HP9000_PA_8000
OS-release : HPUX11.00

I 've found a work-around: If I split my ascii file data in a number of ascii files (to be precise: for each separate processing stream in the report script a separate file) the processing ends oke (apiserver exits!)

The only problem remaining is the processing of purchase invoices with a ttyp that is 'PurchaseOrderRelated' (if you know what I mean). The problem there is the following:
1. If I enter the receipts via AFS in tfacp1131/1132s000 and subsequently approve via tfacp1140 my first invoice is processed oke (batch is balanced and can be processed)
2. If the ascii file contains another invoice to be processed the first AFS call to tfacp1131 for the second invoice will result in a hang situation.

This problem I can work around by splitting once more the ascii files for this type of documents: If each ascii file contains only one invoice the processing is oke.

So I can make it work; only thing is: my cheeks flush if I have a look at the coding that is necessary. It's not very elegant to say the least.

I wonder if my problems could be caused by the thing you mentioned (SSA incorporating their warehouse product in sp18). I can imagine that tfacp1131/1132 are also changed because of this. Agree?

Kind regards,

Henny

I can not really say if that is the case - so far I have not had any problems in the tf package. I do know where all the warehouse stuff went - I only have a few sessions with source code. Luckily the lot controlled session was one.

Another thing I have done in the past:
Have you tried processing more than one record in debug mode? stepping through each line - for two records. I have had api code work this method but not work when a normal compile is done. In some of these cases I have added a suspend statement to get them to work.