VI - Work Order

[Blorf]

Hello.

I need to build an interface to Mas to generate and auto populate work orders.

This I can do with VI, but there are some issues I don't fully understand.

I can build a VI job for work orders, that includes the work order header and the Material Details. The work order header has a Routing Number field, but issuing the Routing Number to the header, does not populate the routing data.

I understand that the routing data has to be entered through a second VI job. No problem, however, back to the header, the labor and over head costing are based on the routing step information. Will populating the routing information force mas to calculate those costs into the header?

I don't belive so. I am gussing I have to calculate costs before I import any thing, and include in the first job, but this seems kind of silly.

Any body have any advice, or know of any references that go beyond the extremely limited manual that comes with the module?

Thank you,
ChaZ

There Are 10 Types Of People In The world:
Those That Understand BINARY And Those That Don’t.

http://mysite.verizon.net/res0n4sv/

 

[flarsen]

I had a similar problem on importing workorders and not calculating the totals. I found that using the perform logic on the import itself and changing the ON SUCCESS to
../ar/arwvip;AR_INVOICE_CALC did the trick. Additionally if one record failed on the import, the whole import failed to calculate I then changed the ON FAILURE perform logic to the same as the success. Now if one record fails the rest of the records do calculate correctly. Hope this helps.

 

[Blorf]

Hi Flarsen. I will try it.

I see that your on success is calling an AR instruction. Are you sure we are talking about work orders?

Thanks,
ChaZ

There Are 10 Types Of People In The world:
Those That Understand BINARY And Those That Don’t.

 

[flarsen]

Hi Blorf,
I may be leading you in the wrong direction. Here at work we have workorders that are created outside mas. I then have to import them into AR_INVOICE for billing. Sorry for my misunderstanding. You know how we programers are, we tend to live in our own little worlds.

Frank