Hello,

A few questions for you:

1. What version are you on and what patch level?

2. Are you receiving this within the data process log (as seen from the web service tester)?

*Description subprogram [WJZBOD]

 NbErrors[1] NbWarnings[0]

 *MENUS DESCRIPTION

   NbErrors[0] NbWarnings[0]

   [Comments]

   Menus : local menus loaded.

 *FIELDS DESCRIPTION

   NbErrors[0] NbWarnings[0]

   [Comments]

   load GRP [BOH0_1] dim=[1]

   load GRP [BOH0_2] dim=[1]

   load GRP [BOD1_1] dim=[100]

   load GRP [ADXTEC] dim=[1]

   Screens : [47] fields and [4] groups loaded.

 *LEFT LIST DESCRIPTION

   NbErrors[0] NbWarnings[0]

   [Comments]

   LeftList : fields and [1] groups loaded.

 *KEY DESCRIPTION

   NbErrors[1] NbWarnings[0]

   [Comments]

   KeyFiled : [2] fields and [1] groups loaded.

   *GROUP [KEYS]

     NbErrors[1] NbWarnings[0]

     *Field [BOMALTTYP]

       NbErrors[1] NbWarnings[0]

       [Err]Local menu [224] not found into X3 description

If so, it seems like the local menu is the issue, at least on my side. Is that what you get?

thanks for looking at this

we are on X3 V6.5

app server 165 release 35 patch 26 - 16v.003

web server WEB.131

yes, I originally got the Local Menu 224 error and realised that this menu was not being included in the publication. The field using this menu (according to the table definition) was BOMALTTYP.

I modified the WebService Publication in Development->Processes->Processes->WebServices and inserted the BOMALTTYP field into the field mapping. i inserted it as the last entry in the BOH0_1 Group

(line 8 in my field mapping list) with the following definition

Selection = ticked

Group = BOH0_1

Level = 1

Code = BOMALTTYP

Internal Name = BOH0_1~BOMALTTYP

Length = 3

Menu = 224

Dimension = 1

Mandatory = No

Argument Type = Hidden

I then published the service and it included the Local Menu 224 definition in the WSD

The WSD now works

But

For some reason now it only finds BOMALTTYP=  1 (Sales kits)

Hi,

Did you find an answer to this?

Thanks

The accidental emoticon translation is funny.

Hi
No, never found an answer. We are still unable to use the ZBOM publication

yes, 2nd one very apt

Seeing the local menu error when you first publish the object makes me think that the entire BOM object in web services isn't going to work correctly and will need to be fixed in a patch.

Hi,

So, if we want to work with BOD object sage need to provide us with a patch? Do you know to get a patch from sage?

Thanks

A support ticket would need to be entered with Sage for this. They'll investigate what needs to happen to make it function correctly and request a patch from R&D for a fix. That fix will be included in a future patch of V6 or roll-up update in V7 but typically hot-fixes can be created if they will work on your current patch level.

Hi,

I did create a support request and waiting for sage still. I hope that they can provide a hot fix.

Thanks for your help. Appreciate it a lot. I will write back to this post when i have an update.

I read (or was told can't remember) that only "certain" objects are published as standard in X3 and others may need individual coding (aka chargeable!)
I took it from this that BOD was possibly not one of the standard ones - but would be great to hear if you get an answer to your support log

You are right. I had forgotten that they say that. I ran into that when I was trying to create contact objects via web services. Is there a reason why you are trying to use web services for BOD? I've written an intranet application and I had first written it with quite a bit of web service calls. Unfortunately, the overhead was causing such a lag that I changed to most of my read ops to be straight SQL calls with a read-only SQL user.

Hi,

I though of using web services due to two reasons. First, that is what sage recommends. They don't really like us playing with database directly. Second, i have to create, update production BOMs, so a read only access will not be enough for us. I am hoping that sage can fix this. If not i have to use direct SQL to read records and write few sub programs and expose them via web services to write data back. Unfortunately i am not creating this application for internal use. This has to be like an OEM package where we can deploy to different customers. This enforce us to follow sage guidelines and best practices.

Thanks

We had a similar problem trying to Import BOMs using Import/Export Templates and tracked the problem down to an incorrect default for the BOM type in standard code. We added this to SPEBOD to solve our problem;

$ACTION
Case ACTION
When "AVANT_OUVRE" : Gosub AVANT_OUVRE
When Default
Endcase
Return

$AVANT_OUVRE
If GIMPORT Then
GFONBOD = "BOMP"
Endif
Return