Hi,

I'm having problems with the tdput4210m000 session (Maintain receipts) that i'm trying to automate using stpapi.

After I fill the "dino" field I do a save which should call up the select order subsession (like it happens manually).


baanobj.putfield(sessaorep, "form.dino", "5454");
baanobj.handlesubproc(sessaoref,sessaoorder,"add");
baanobj.save(sessaorep);
baan.obj.putfield(sessaoorder,"form.ordo","100030");

It hangs after put.field in the subsession. After watching the messages in the console output I see when put.field is called that a createobject is called and then a killprocess. After the killprocess it simply hangs.

I tried not to call the subsession and insert the info directly:

baanobj.putfield(sessaorep,"tdpur45.orno","100030");
baanobj.putfield(sessaorep,"tdpur45.pono","10");
baanobj.putfield(sessaorep,"tdpur45.diqu","4000");
baanobj.putfield(sessaorep,"tdpur45.date",
baanobj.toBaandate(DateTime.Now.ToShortDateString()));
baanobj.putfield(sessaorep,"tdpur45.dqua","4000");

baanobj.putfield(sessaorep,"tdpur45.copr","50,00");
baanobj.insert(sessaorep,1,ref err);

But I get a "no plan of costs for this date exists" (translated) error message.

Can anyone give me a hint here? :)

Thanks in advance,

Take a look at these threads they should be of some help.

http://www.baanboard.com/baanboard/showthread.php?s=&threadid=5639
http://www.baanboard.com/baanboard/showthread.php?s=&threadid=696
http://www.baanboard.com/baanboard/showthread.php?s=&threadid=682

Hi Darren,

Thanks for the answer but I had already searched and read all those threads. I still have the same problem.
I was hoping someone who automated this session already, could give me a hint if this can be a Baan problem requiring a solution or tell my code is totally wrong.
I think I tried almost everything to make it work but maybe I'm missing something obvious :)
I forgot to mention we have supply chain too.....

I think in this thread the problem is similar but there is no follow up:
Other thread (http://www.baanboard.com/baanboard/showthread.php?s=&threadid=6201)

Thanks once more

I also have supply chain I am not in work for a few days but will try it on my system when I get back.

Don`t know if this idea is of any use but I have setup a system to maintain receipts via loading the delivery data to the ASN tables and Production Control receipt against the ASN.

Thanks Darren,

I also have the lot control subsession. I tried to do exactly the same, handle.subproc followed by a changeview or a put.field and it hangs too....I'm starting to think this a Baan problem.
I don't see any reason for it to hardlock....If the subsession doesn't exist it should return an error message. :rolleyes:

Darren and all,

I managed to make it work compiling it in a Baan DLL.
If I call the same code from the outside it hangs but calling a DLL from the outside works.

Now I have another problem. We have to use the tdpur4131s000 because of supply chain instead of the order selection subsession.


stpapi.handle.subproc( "tdpur4120m000", "tdpur4131s000", "add")
| tdpur4131s000 subsession
ret = stpapi.change.view("tdpur4120m000")
stpapi.put.field("tdpur4131s000", "tdpur45.orno", "100030")
stpapi.put.field("tdpur4131s000", "tdpur45.pono", "10")
ret=stpapi.find("tdpur4131s000")
ret=stpapi.mark("tdpur4131s000")
stpapi.continue.process("tdpur4131s000", err)
if(strip$(err)<>"" and strip$(err)<>"Process is gone") then
Message("process error = %s",err)
endif
| end the subsession.
stpapi.end.session("tdpur4131s000")


I have a very strange behaviour. If I do it like this both mark and find functions return 1 which is ok. But when I go back to the main session I don't have any record in the multi-oco list. Now this happens when I use the orno and pono fields as the session index with ref 1. If I use other session indexes the above code works (when I go back to the main session I have multi-oco first line filled) but I don't get the correct record (I always get the first record - I guess this is correct behaviour because the find function doesn't use the specified fields if I use other indexes).

Is this normal? A bug with stpapi maybe?

Thanks in advance,

I have not had this actual problem, but I have had instances where a sub-session gets activated with the incorrect record. In these cases I was able to get around the problem by doing a find. I have never had a main session return to the incorrect record. It could be because of the indexes you mentioned.

Sometime in the next couple of months I will be doing a Maintain Receipt FS. At that time I may be more knowledgable about what happens with them. I have not had time to look at this yet. I will try to keep this post in mind when I do the function server.

Mark

Mark,

Thanks for the answer. Maybe I explained myself wrong here.
When the correct index is specified my problem is not getting a record at all in the main session, the find function works ok because I did a get.field in the subsession after the find and the I get the correct data.
I only get different records in the main session when I specify the pono and orno fields and change the index to something else but at least it returns some data :)

I have seen several posts in this forum about type 3 forms and change.view. Maybe that is the problem? I only do a change.view to activate the subsession.

Thanks :cool:

After doing a change view, you should then do a find. Also, as you have read then, the find is not always reliable. If the find is not working, but your change view is, try using the browse.set commands with the get.field's to determine the correct current record, then even the 'mark' command to mark the record before 'continue'.

Hi all,

I did a stupid mistake. :rolleyes:
The fields are not tdpur45.* but tdpur045.*. Nevertheless the OLE problem still remains but I can live with it since I have found the Baan DLL to be much faster.
So if anyone needs it the code that works is:


| Preparar para a subsessao
stpapi.handle.subproc( "tdpur4120m000", "tdpur4131s000", "add")
| Activa a subsessao de escolha por fornecedor
ret = stpapi.change.view("tdpur4120m000")

stpapi.put.field("tdpur4131s000", "tdpur045.orno", "100030")
stpapi.put.field("tdpur4131s000", "tdpur045.pono", "10")
ret=stpapi.find("tdpur4131s000")
ret=stpapi.mark("tdpur4131s000")

stpapi.continue.process("tdpur4131s000", err)
if (strip$(err) <> "" and strip$(err)<> "Process is gone") then
Message(" Erro na subs. tdpur4131s000 = %s",err)
endif
| Desligar a subsessao
stpapi.end.session("tdpur4131s000")


Now I will continue the rest of the fields and lot subsession. I will post more code later if it works.
Thanks for all the help,

I have had luck with AFS for other sessions, but the sub-session that is activated from Maintain Receipts (when ILC is active) gets activated when you 'tab off' of the Rec. Date field but I am having difficulty with it.

I have gotten the main session to delete a PO line from a receipt number as a test so I know AFS is talking to tdpur4120m000.

When I run the following code, it freezes at the line highlighted with ***** (in the debugger, control is never returned)


pur4120 = "tdpur4120m000"
ilc4113 = "tdilc4113s000"

stpapi.put.field(pur4120, "tdpur045.reno", "1550")
stpapi.put.field(pur4120, "tdpur045.orno", "110424")
stpapi.put.field(pur4120, "tdpur045.pono", "12")
e = stpapi.find(pur4120, error.message)
if e <> 1 then
|* Receipt not found!?!
else
stpapi.handle.subproc(pur4120, ilc4113, "add")

stpapi.put.field(pur4120, "tdpur045.diqu", "20")
stpapi.put.field(pur4120, "tdpur045.date", str$(date.num()))


stpapi.put.field(ilc4113, "tdilc402.clot", "5111") ******
stpapi.put.field(ilc4113, "tdilc402.date", str$(date.num()))
stpapi.put.field(ilc4113, "tdilc402.stun", "ea")
stpapi.put.field(ilc4113, "tdilc402.qstr", "20")

e = stpapi.save(ilc4113, error.message)
if e <> 1 then
e = stpapi.recover(ilc4113, recover.message)
endif
stpapi.end.session(ilc4113)
endif
stpapi.end.session(pur4120)



In order to make my life easier (I read all of the previous post regarding difficulty with the other sub-session for selecting order lines) I have gone a different route and just created the new record in tdpur045 with the receipt #, packing slip number and new sequence number. This has worked for me in the past for other receiving issues.

So the above code is entering the session, then looking for the pre-entered receipt number, PO and POL. Then I enter the packing slip quantity and the receipt date but I can not seem to get the ILC subsession to "pop" up so that I can maintain data within it.

In many of the previous posts, there is a reference to the use of stp.change.view(). Even though this did not make sense, I tried it with no luck.

Mark... did you ever get around to automating this session as you mentioned above?

Cheers,

-Dennis

PS: If this should have been a new post, my appologies.

Here is the code to modify a receipt. I have not tested it in our 4c4 version.


Mark

function extern modify_receipt( domain tcrcno receipt.number,
domain tcorno purchase.order,
domain tcpono purchase.line,
domain tcqiv1 packingslip.qty,
domain tcqiv1 received.qty,
domain tcdate received.date,
domain tdltc.clot purchase.lot,
domain tcdate purchaselot.date,
ref string msg())
{
long rc, cnt
string dummy(6)
domain tcorno get.orno
domain tcpono get.pono
stpapi.put.field("tdpur4120m000","tdpur045.reno",str$(receipt.number))
stpapi.put.field("tdpur4120m000","tdpur045.orno",str$(purchase.order))
stpapi.put.field("tdpur4120m000","tdpur045.pono",str$(purchase.line))
rc = stpapi.find("tdpur4120m000",msg)
if not isspace(msg) or rc<>1 then
stpapi.end.session("tdpur4120m000")
return
endif
stpapi.get.field("tdpur4120m000","tdpur045.orno",dummy)
get.orno = val(dummy)
stpapi.get.field("tdpur4120m000","tdpur045.pono",dummy)
get.pono = val(dummy)
cnt = 1
while get.orno<>purchase.order and get.pono<>purchase.line and cnt<10
stpapi.get.field("tdpur4120m000","tdpur045.orno",dummy)
get.orno = val(dummy)
stpapi.get.field("tdpur4120m000","tdpur045.pono",dummy)
get.pono = val(dummy)
cnt = cnt + 1
endwhile
| Prepare to handle lot controlled items.
if not isspace(purchase.lot) then
stpapi.handle.subproc("tdpur4120m000","tdilc4113s000","add")
endif

stpapi.put.field("tdpur4120m000","tdpur045.diqu",str$(packingslip.qty))
stpapi.put.field("tdpur4120m000","tdpur045.date",str$(received.date))
stpapi.put.field("tdpur4120m000","tdpur045.dqua",str$(received.qty))
stpapi.update("tdpur4120m000",1,msg)
if not isspace(msg) or rc<>1 then
if not isspace(purchase.lot) then
stpapi.end.session("tdilc4113s000")
endif
stpapi.end.session("tdpur4120m000")
return
endif

if not isspace(purchase.lot) then
stpapi.put.field("tdilc4113s000", "tdilc402.clot",purchase.lot)
stpapi.put.field("tdilc4113s000", "tdilc402.date",str$(purchaselot.date))
stpapi.put.field("tdilc4113s000", "tdilc402.qstr",str$(received.qty))
stpapi.put.field("tdilc4113s000", "tdilc402.qstc",str$(received.qty))
stpapi.insert("tdilc4113s000",1,msg)
stpapi.get.mess.code("tdpur9401m000",msg)
stpapi.end.session("tdilc4113s000")
endif
stpapi.end.session("tdpur4120m000")
}

Also note if you are doing a supply chain receipt - they fall through much the same, but that second session is then tdilc4114s000.

First off - thank you Mark for you quick response. ... and thank you Ibencic, but no we are not supply chain.

I have changed my code in many different ways (including an almost exact match to Mark's above) with no luck.

The following is the end of the AFSLOG file that is created when debugging:
16<-def.find
0
1
<tdpur4120m000 record found (1)
>tdpur4120m000 handle.subproc tdilc4113s000 add
>tdpur4120m000 put.field:tdpur045.diqu 20
>tdpur4120m000 put.field:tdpur045.date 731469
>tdpur4120m000 put.field:tdpur045.dqua 20
>tdpur4120m000 update
16->modify.set+save
17<-api.child.startedtdilc4113s00016
17->get.fields
16<-modify.set+save
0

It seems that when the program requests the 'get.fields' on the subsession that is where it never comes back. As one of the many tests, I ommited the handle.subproc and then just shut down the main session after the update and it shut down without a problem.

Are there variables that tdilc4113s000 expect to be set up that I would have to set up in my script? I would assume that tdpur4120m000 would do all of that.

One thing that has got me thinking is that I can not start up the subsession from maintain sessions... I know it is a subsession an all, but it just freezes as opposed to starting up with no data like most subsessions. Does anyone who has the code see any reason why this subsession is acting that way? Can someone else just try to start tdilc4113s000 from Maintain Sessions to see if it freezes for you please?

I appreciate all of your help... One thing that I should mention is that we are multi-currency and this particular session's PS has been pulled up to the MCR VRC. I guess I should call BAAN and check that whatever they did for MCR did not break AFS.

Cheers,

-Dennis

Yes the tdilc4113s000 session locks up from maintain sessions. I found this on the quick guide from baan:
td B40 c ilcf4113s000 tdilc4113s000 115649 Maintain Receipts (ILC)
td B40L c bci0 ilcf4113s000 tdilc4113s000 103385 Maintain Receipts (ILC)

The 115649 and 103385 are the solution numbers that Baan supports. I am not sure if these should be installed at your site or not because of the multi-currency issue.

I also have not tested my API code on 4c4. Our users do not have access to that version yet. I will try in the next week or so to get it move there so I can test it.

Mark

Hi Dennis/Mark,

Yes, the subsession tdilc4113s000 always freezes.

I was trying to automate the Replenishment Receipts session (tdrpl0122m000). We have implemented ILC and as a result, the tdilc4113s000 session pops up.

When I tried debugging it manually, I realized that the session requests for data from tdilc402 and at that moment tdilc402 has no record for that order. As a result, when we try to maintain any data, the session freezes. I am not sure if its data related, but if you go through the AFS guideand refer page 5-3 (Hidden Functionality) it causes more confusion.

Dennis, I had the same problem with the Maintain Purchase Receipts program, but I avoided the popping up of tdilc4113s000 by modifying the Distribution Paramater:
Maintain Receipts by Receipt/Order Number in tdpur4100m000
and set it as "By Order" and I also ensured that the "Storage Unit for Inbound Advice" in tdilc0100m000 is set to No.

This allows me to maintain receipts by order number and does not pop up tdilc4113s000

Drawbacks of this approach:
1. This assumes that the inventory and storage units of the Item are the same
2. Item is not Lot Controlled
3. Outbound Priority of the item <> FIFO or LIFO (Outbound Priority = 'By Location')

If someone has any answer regarding tdilc4113s000, please post your suggestions here.

As I went through all the posts, I relaized that till now no one had been able to figure out a way to handle tdilc4113s000. Or am I wrong?

Regards

My bad! Got a solution from BAAN within a week of this post (one of those rare instances where the person they assign is the person who did the work that "broke" the session in the first place. I put "broke" in quotes as he did what he was told by another department but he realized it would be confusing to us AFS folks).

In your code define the variable boi.call as follows:


extern domain tcmcs.str132 boi.call


and then fill it with:


boi.call = "tdboidll0011.Create"


You can fill it right at the start of tdpur4120m00 - it does not seem to affect it in any adverse ways.

Hope you have luck with this!

Cheers,

-Dennis

Dennis,

Just thought I would let you know that I developed my receiving program in 4c3 and tdilc4113s000 worked just fine without the BOI call. We are converting to 4c4, the program was moved to this environment and worked. We are going live on 4c4 this weekend, so the users decided to do some last minute testing on this program(which will not be part of the go live) and the session started hanging on lot controlled parts. We must have installed a solution that changed something. Anyway, I remembered this post and used what you posted. It now works again.

Thanks!

Mark

Hi Mark/Dennis,

The tdilc4113s000 session hangs when I am using it with Maintain Replenishment Order Receipts-tdrpl0122m000

Did you ever encounter this?
Dennis, I tried assigning the boi.call = "tdboidll0011.Create"
But, it still does not work.

Any thoughts?

Regards,

FoxZapper,

First I would check to see if the variable boi.call fixes you purchase receipts to see if it is doing anything - maybe you have an old object that does not even know about boi.call yet?

From what I understand, not only tdilc4113s000 must work with the variable boi.call, but also the calling program must import("boi.call", boi.call) as well. In my case this was tdpur4120m000 so I really don't know if tdrpl0122m000 also has this import command.

If it does work with the purchase session, then my next step would be to submit a call with BAAN. I am embarassed to say that I was amazed that once they got back to me, I had my answer within a few days... I was very worried that this was one of those problems that would never get an answer when I submitted it.

If the purchase AFS does not work as well... then I would check to make sure you have the most recent objects

Cheers,

-Dennis

PS: Just making sure, but you did define boi.call as extern right?

Hi Dennis,

Thanks for your response. (And please call me Arun)
tdpur4120m000 works fine because I ensured that tdilc4113s000 does not pop up (by modifying Purchase Parameters)

Yes, I have declared the variable as an extern.

And I believe we have the latest object since we recently installed BaaN IV c4's Service Pack 12

The oboidll0011 object in td (Standard) is dated 26th November 2003


Here is my script:


function maintain.replenishment.order.receipts.in.baan()
{
|* This function imports the replenishment receipts
long ret.val1, ret.val2, ret.val3, ret.val4
string errs(256) | Error returned by AFS
domain tcorno order.number.get.next
domain tcpono position.number.get.next

|* Fields required per line
domain tcsrnb srnb | Delivery number

order.number.get.next = val(order.no.str)
position.number.get.next = val(order.line.str)


|* Determine the delivery number for this receipt
select tdrpl100.orno, tdrpl100.pono, tdrpl100.srnb
from tdrpl100
where tdrpl100._index1 = {:order.number.get.next, :position.number.get.next}
order by tdrpl100._index1 desc
as set with 1 rows
selectdo
srnb = tdrpl100.srnb
selectempty
err.mesg = "Order - (" & order.no.str & ") does not exist"
create.err.file()
endselect

|* Call the session tdrpl0122m000, and locate the order
stpapi.put.field("tdrpl0122m000", "tdrpl100.orno", order.no.str)

ret.val1 = stpapi.change.view("tdrpl0122m000", errs)
if ret.val1 = 1 then
stpapi.put.field("tdrpl0122m000", "tdrpl100.pono", order.line.str)
stpapi.put.field("tdrpl0122m000", "tdrpl100.srnb", str$(srnb))
ret.val2 = stpapi.find("tdrpl0122m000", errs)
if ret.val2 = 1 then
|* Enter the date and quantity
stpapi.put.field("tdrpl0122m000", "tdrpl100.rrdt", str$(date.num()))
stpapi.put.field("tdrpl0122m000", "tdrpl100.pqua", quantity.str)

stpapi.handle.subproc("tdrpl0122m000", "tdilc4113s000", "add")
boi.call = "tdboidll0011.Create"

|* Function to get sera and serb
get.next.sequence.number.for.replenishment.sera.serb.from.tdilc402()

stpapi.put.field("tdilc4113s000", "tdilc402.orno", order.no.str)
stpapi.put.field("tdilc4113s000", "tdilc402.pono", order.line.str)
stpapi.put.field("tdilc4113s000", "tdilc402.sera", sera.str)
stpapi.put.field("tdilc4113s000", "tdilc402.serb", serb.str)
stpapi.put.field("tdilc4113s000", "tdilc402.item", item.no.str)
stpapi.put.field("tdilc4113s000", "tdilc402.stun", unit.str)
stpapi.put.field("tdilc4113s000", "tdilc402.qstc", quantity.str)
stpapi.put.field("tdilc4113s000", "tdilc402.qstr", quantity.str)

ret.val3 = stpapi.insert("tdilc4113s000", true, err.mesg)
|* Could try a Save?

if ret.val3 <> 1 then
|* If error, then recover the session
ret.val4 = stpapi.recover("tdilc4113s000", errs)
create.err.file()
else
success.rec = success.rec + 1
first.time = false
endif
else
err.mesg = "Order-(" & order.no.str & ") Line-(" & order.line.str & ") could not be opened"
create.err.file()
endif
else
err.mesg = "Order - (" & order.no.str & ") could not be opened"
create.err.file()
endif
stpapi.end.session("tdilc4113s000", errs)
stpapi.end.session("tdrpl0122m000", errs)
}

I do believe there is a later version of tdilc4113s000. We received a version with SP 13 - at least that is what the PMC Report is saying. My original 4C4 code worked, a patch was installed , then it stopped working, that was when I added the BOI call.

What in your code activates the 4113 session? Just curious because I do not see a continue,insert, or anything before you start inserting into the 4113s000 session.

Mark

Hi,

Although I'm using OLE to receive replenishment orders, I believe the following sequence will work for you.

I do the 3 puts ("tdrpl0122m000", "tdrpl100.orno", ...pono, ...srnb) then do the "find".
Then put ("tdrpl0122m000", "tdrpl100.rrdt"). I don't put the quantity as this is entered in the subsession.
Here's where we differ.
Do an update to tdrpl0122m000.
Subsession tdilc4113s000 should now be running.
The only thing I put into tdilc4113s000 is tdilc402.qstr. The other fields seem to self-populate.
Then I do the insert for tdilc4113s000.

I hope this helps.
Al.

Hi Mark/Al,

First off, thanks for the help guys.

First to answer Mark:
We have installed SP-14
1. The boi.call code for Replenishments is still a gray area, since we only have a solution for Purchase Receipts from BaaN. (It was posted by Dennis)
2. The tdilc4113s000 session is activated the moment you navigate to the quantity field. No continue or update is required.
I believe, you must have a code for tdpur4120m000 which activates tdilc4113s000. An activation is required for Purchase Receipts (I believe it is continue).

Al:
You da man!
I applied your approach and the code works like a charm.
What I can't understand is why do we need to update tdrpl0122m000? Al, I would like to know why you did this?

Can someone (Mark/Dennis/Al/Nico) tell me what boi.call should be equal to?

boi.call = "tdboidll0011"
or
boi.call = "tdboidll0011.Create"


I have a case pending with BaaN, and if I get a solution for other sessions, I shall post them here.

For anyone else who needs the working code for Replenishment Receipts with Location Control, here it is:

Regards,

Arun


function maintain.replenishment.order.receipts.in.baan()
{
|* This function imports the replenishment receipts
long ret.val1, ret.val2, ret.val3, ret.val4, ret.val5
string errs(256) | Error returned by AFS
domain tcorno order.number.get.next
domain tcpono position.number.get.next

|* Fields required per line
domain tcsrnb srnb | Delivery number

order.number.get.next = val(order.no.str)
position.number.get.next = val(order.line.str)


|* Determine the delivery number for this receipt
select tdrpl100.orno, tdrpl100.pono, tdrpl100.srnb
from tdrpl100
where tdrpl100._index1 = {:order.number.get.next, :position.number.get.next}
order by tdrpl100._index1 desc
as set with 1 rows
selectdo
srnb = tdrpl100.srnb
selectempty
err.mesg = "Order - (" & order.no.str & ") does not exist"
create.err.file()
endselect

|* Call the session tdrpl0122m000, and locate the order
stpapi.put.field("tdrpl0122m000", "tdrpl100.orno", order.no.str)

ret.val1 = stpapi.change.view("tdrpl0122m000", errs)
if ret.val1 = 1 then
stpapi.put.field("tdrpl0122m000", "tdrpl100.pono", order.line.str)
stpapi.put.field("tdrpl0122m000", "tdrpl100.srnb", str$(srnb))
ret.val2 = stpapi.find("tdrpl0122m000", errs)
if ret.val2 = 1 then
|* Enter the date and quantity
stpapi.put.field("tdrpl0122m000", "tdrpl100.rrdt", str$(date.num()))
stpapi.handle.subproc("tdrpl0122m000", "tdilc4113s000", "add")
ret.val4 = stpapi.update("tdrpl0122m000", true, err.mesg)

if ret.val4 = 1 then
boi.call = "tdboidll0011"

get.next.sequence.number.for.replenishment.sera.serb.from.tdilc402()

stpapi.put.field("tdilc4113s000", "tdilc402.orno", order.no.str)
stpapi.put.field("tdilc4113s000", "tdilc402.pono", order.line.str)
stpapi.put.field("tdilc4113s000", "tdilc402.sera", sera.str)
stpapi.put.field("tdilc4113s000", "tdilc402.serb", serb.str)
stpapi.put.field("tdilc4113s000", "tdilc402.item", item.no.str)
stpapi.put.field("tdilc4113s000", "tdilc402.stun", unit.str)
stpapi.put.field("tdilc4113s000", "tdilc402.qstc", quantity.str)
stpapi.put.field("tdilc4113s000", "tdilc402.qstr", quantity.str)

ret.val3 = stpapi.insert("tdilc4113s000", true, err.mesg)
if ret.val3 <> 1 then
|* If error, then recover the session
ret.val5 = stpapi.recover("tdilc4113s000", errs)
create.err.file()
else
success.rec = success.rec + 1
first.time = false
endif
else
create.err.file()
endif
else
err.mesg = "Order-(" & order.no.str & ") Line-(" & order.line.str & ") could not be opened"
create.err.file()
endif
else
err.mesg = "Order - (" & order.no.str & ") could not be opened"
create.err.file()
endif
stpapi.end.session("tdilc4113s000", errs)
stpapi.end.session("tdrpl0122m000", errs)
}

Arun,

From what I understand, boi.call is a variable that was added to help the OW folks make one session do different things when called from different places. In a perfect world... we would not even need to know about it.

There are two answers to your question above as to how it should be set:

1) From BAAN, it should be set: boi.call = "tdboidll0011.Create"

2) Thinking that if your code is working, then however you set it is just fine!

Cheers,

-Dennis

Dennis/Mark and others,

Apparently, there is a whole list of many such boi.call string declarations that have to be declared before any AFS program is accessed. The one you(Dennis) mentioned is not available on BaaN Support.

For instance, before inserting Sales Order Lines, you have to declare boi.call as "tdboidll0005".

This is what BaaN had to say about that:

Some changes and improvements have been made to some standard scripts to resolve some issues related to the standard iBaan Domain Pack BOIs. This involved the introduction of the "boi.call" variable. This variable will be used going forward in conjunction with the "api.mode" variable to handle both AFS and BOI calls. This new variable will be supported going forward, and is a solution to the problem, not a workaround.


I am trying to get such a list (if it exists!) from BaaN for us folks.
Shall post it here as and when I get them.

Regards,

Arun

Dennis,

I know it as been a while since you posted it.
But thanks for the solution with boi.call variable.
We just moved some service packs up and it broke the receipts function server which turns out to be one of the most important we have.

I just used the boi.call and it worked :)

Thanks.

Glad this post was of assistance... it's what makes this board work so well... all of the active contributors! :)

-Dennis

...

I am trying to get such a list (if it exists!) from BaaN for us folks.
Shall post it here as and when I get them.

Regards,

Arun

Arun,

Did you ever get this list?

Cheers,

-Dennis

Dennis,

You know what?
I really tried...
I think there is no clear answer at BaaN. Maybe they haven't documented it?

Finally, I lost my patience.
I will definitely put them here when I get them.

Regards,

Arun

Arun,

Well, that's a shame. I have run into another AFS issue and it looks mysterious enough that I think it is another variable issue.

I have a session that performs inventory adjustments that works fine when run normally but when it is run in a job, it just keeps coming back "Process is gone" where it would normally reply back with the fields I am filling. From the text, it looks like everytime I issue an stpapi.put.field command it tries to start the session and aborts with the above error message.

I have a case open, but things are not moving too fast.

Cheers,

-Dennis

Code and log file
long returnval
string error.message(100)
string recover.message(100)
string ilc1120(13)
string ilc1121(13)
string hold.wrho(10)
string hold.cuni(3)

ilc1120 = "tdilc1120m000"
ilc1121 = "tdilc1121s000"
returnval = 0
error.message = ""
recover.message = ""

stpapi.put.field(ilc1120, "tdinv100.cprj", "")
stpapi.put.field(ilc1120, "tdinv100.item", i.item)
stpapi.put.field(ilc1120, "tdinv100.cwar", i.cwar)
stpapi.put.field(ilc1120, "tdinv100.idat", str$(date.num()))
stpapi.put.field(ilc1120, "tdinv100.kowt",
str$(etol(tckowt.stc.correction)))
stpapi.put.field(ilc1120, "tdinv100.recd", i.recd)
stpapi.put.field(ilc1120, "tdinv100.odat", str$(i.date))
stpapi.put.field(ilc1120, "tdinv100.pdat", str$(i.date))
stpapi.put.field(ilc1120, "tdinv100.trdt", str$(i.date))
stpapi.put.field(ilc1120, "tdinv100.pqan", str$(i.pqan))

if not stpapi.insert(ilc1120, true, error.message) then
do.error(i.msgn, i.ftyp, i.seqn, returnval,
"API:" & error.message)
stpapi.recover(ilc1120, recover.message)
if strip$(recover.message) <> "" then
do.error(i.msgn, i.ftyp, i.seqn, returnval,
"API:" & recover.message)
endif
else
.....
LOGGING STARTED
08-23-2004
47->get.fields
47<-exit.child
47<-^AProcess is gone
48->get.fields
48<-exit.child
48<-^AProcess is gone
49->get.fields
49<-exit.child
49<-^AProcess is gone
50->get.fields
50<-exit.child
50<-^AProcess is gone
51->get.fields
51<-exit.child
51<-^AProcess is gone
52->get.fields
52<-exit.child
52<-^AProcess is gone
53->get.fields
53<-exit.child
53<-^AProcess is gone
54->get.fields
54<-exit.child
54<-^AProcess is gone
55->get.fields
55<-exit.child
55<-^AProcess is gone
56->get.fields
56<-exit.child
56<-^AProcess is gone
>tdilc1120m000 insert
>tdilc1120m000 recover
>tdilc1120m000 end.session

Lots of things can kill the api's, but one biggie is the execute(end.program) in the session you are trying to execute.

In tdilc1120, they have 2 of them, both in the before program section.

1. If the company does not have ILC turned on. I am assuming since this runs normal this can't be the case.

2. If the user does not have permission (Maintain User Authorizations for Inventory Transactions) it will call the end.program. They put a patch for this not to call the end program if they are in api.mode. That's in the solution: SOL 114964

Is you're tdilc1120 program fairly current? You can check for that solution, (if you run ttstpsessinfo, it's in there as that number). It's dated 2001 though, so probably have it. But if not, maybe your job user is not authorized to run this, it would cause such a problem.

Lisa,

:eek: Wow... I used to live in a world with source but that was in a previous life as a consultant and I forget how simple a solution can be if you can see what is happening. Thanks for the pointer!

The job user had been removed from the authorization list for inventory transactions in this company and this explains why it used to work in the job but started not working about 2 months ago...

The fact that it had just stopped working (with no patches during the suspect time) was so strange, that I was questioning my memory that it had ever worked in the job and had almost convinced myself that it maybe had never worked in the job.

Thanks again,

-Dennis

PS: Just did a bic_info on tdilc1120 and I don't have that patch - but we are on MCR so we sometimes don't get all of the patches in our VRC - I KNOW that we have received a PMC of this session since 2001!

Just thought I would let you all know that my receiving program stopped working for the latest service pack. I was lucky in the fact that I could set a new variable called g.sub.session to true. This allowed the program to activate the tdilc4113s000 session. So far it looks like it solved the problem - I also found several more boi.call type things to set. I do not think my fix should be required and will place a call with Baan. In the mean time I will leave this in place.

Mark,

We just installed a bunch of patches (maybe it was a service pack - I don't look after these things) and my receiving is not working anymore.

I added a long called g.sub.session as you suggested and set it "= TRUE" and it still hangs.

Any more info?

Cheers,

-Dennis

Which part hangs? Where it activates tdilc4113s000? Do you have boi.call set? You may have to set it to boi.call = "tdboidll500015.Create" or "tdboidll0011.Create". I can not really know with out looking at the source for the session. You may want to ask Baan for the current source to see why it does not work and to report this is not working in api.mode. It looks like they used a lot of "if api.mode then" for this wms integration which causes problems for the normal api sessions.

I know there are newer patches than the service pack 18 patches that we installed. I had to make several changes to get the approvals piece working again. I have not tried my code on the most current patches(Service Pack 19). I do know they attempted to integrate that WMS stuff through out the code. It is causing me tons of problems.

Mark,

From the PMC sessions, this session has been hit hard (dozens of updates all loaded just this morning) with WMS modifications. We don't have the source so, I can't see what they have done.

The session hangs when I try to push the first variable to the sub-session - I do the update in tdpur4120m000 and the log shows the session responding, but when I put.field the first fields of tdilc4113s000, the get.field does not get returned and at that point, the session (and log) just hangs.

I have the boi.call = "tdboidll0011.Create" - what is the other setting for? Just something else you have found to work?

-Dennis

Yes it was something I found prior to the current release. A snippet of the code from what may(I do not know if the code matches our object) be our current session is:

if ((boi.call <> "tdboidll500015.Create" ) or
(boi.call = "tdboidll500015.Create" and
g.sub.session ) ) then
|#148648.en
zoom.to.arrivals.in.ilc()
refresh.curr.occ()
endif

No telling what you code may contain. You may want to ask baan for the source code. It took a lot of looking to see what I had to do to get it to work. Are you able to actually control tdilc4113s000? Like when it starts from tdpur4120m000 can you end the session? It took me several days to figure out the approvals session. Do you have access to a wrapper program(RMCgen, Qkey)? I used this to figure out how to get the maintain approvals done.

Mark,

With all of the patches we just installed, we don't have 148648! or at least PMC doesn't think we do. I guess I will have to log a call with BAAN - we don't have source so getting them to let me take a pick is like pulling teeth, but we will see. I don't believe that ilc4113 ever starts - in the log file, I can see the request to 'get fields' which then normally returns with a long string of fields that session uses. In this case, it never comes back and that is very similar to when it broke long, long ago (I think at the start of this conversation :^).

I do have the wrapper program that I got off this board, but I am relatively confident that my code is good - it used to work and the visible BAAN procedures/steps have not changed. We don't use inspections and approvals here, the staff don't like how BAAN rejects material and how no history of the rejection is kept.

Thanks for the thoughts,

-Dennis

Not sure but patch 148648 could be an A&D patch. I will send you a PM.

We use the Tip/QA package with Baan, but we have even automated it. For source inspection and such. Pretty cool when the Baan piece works.

So, with BAAN's help, we ran the session in debug mode using the latest and greatest objects and everything worked. So... while we had just installed over 1K patches, we have to install more to get the receiving session up to current.

You feel a bit stupid when the answer really is ... "are your patches up to date?"

Yep - we ran into the same thing while testing our last service pack. I know our last couple of fixes have been outside PMC control - we did not want to have to test 20 pages of objects when only one was causing the problem. Maybe I should change my mantra to include - "Contact Baan to really and truly find out the answer".

While making my API script for Maintain Receipts fool-proof (please refer to Making API for Maintain Receipts (tdpur4120m000) fool-proof), I found out that you don't have to call stpapi.continue.process("tdilc4131s000",APIErrMsg) there at all. If you must, you'll be better off sending stpapi.update() to that subsession. But, actually, the only command you need to send to that subsession is the stpapi.end.session(). This is because all the actions of that tdpur4131s000 happens in choice.update.db, and choice.end.program actually calls choice.update.db too.
Just a tip for those who would like to save several miliseconds when his/her code runs.

Rgds,
Paul