Message Boards

How to prevent QXO from triggering twice on trigger so_mstr with soivpst,p?

Stephane David, modified 3 Years ago.

How to prevent QXO from triggering twice on trigger so_mstr with soivpst,p?

Post Date: 4/18/13 (Bronze, 7 Posts) Recent Posts
Hello,
We are testing the use of QXtend in order to automate the following processes once a sales order is shipped via Sales Order Shipments sosois.p:

- Print the invoice, based on trigger so_mstr and appropriate filters QXO will use the invoice print program via a qdoc in QXI which we have generated. This works perfectly.

- Post the invoice once the invoice has been printed and updated (Update Yes). Same principle based on appropriate filters with so_mstr QXO will use the invoice post program via a qdoc in QXI which we have generated. This works perfectly.

- Send another QXO subscriber message via a different subscriber to update an external source. This works perfectly.

However another subscriber message gets generated after the first invoice post subscriber message in QXO. This second message does not generate any output since the invoice has already been posted. This happens for both subscriber messages for the invoice post described above.

We suspect this could be because the record disappears from so_mstr and goes to ih_hist. We cannot find any mechanism to prevent this from happening from the filters. There could be a trigger for when so_mstr gets updated with the invoice number and for when the record is moved to ih_hist we can only assume we do not know.

We have also tried to trigger the invoice post on the ih_hist only but we have observed the same behaviour.

Could you please advise? Your insights with this would be much appreciated!

Cheers
Stephane David
thumbnail
Evan Todd, modified 13 Years ago.

Re: How to prevent QXO from triggering twice on trigger so_mstr with soivps

Post Date: 4/21/13 (Rhodium, 699 Posts) Recent Posts
Hi Stephane,

you are right, what you are seeing there is the so_mstr record being transferred to ih_hist and being deleted, so the so_mstr replication-delete trigger is being fired. QXO picks this up and this will flow through the system. You might also see it when the so_mstr changes state, for example it goes from not printed to printed, and you have a filter in your BO.

I don't have much in the way of solutions if you are going to use the database triggers. If the profile is set up to check for Data Operations, then you can filter out the Delete Qdocs in the subscriber.

This type of situation is best solved by using Business Events, as you have far greater control over when they are fired. Depending on the version of QAD you have there, there will be an InvoicePost business event which you could use but for the others you would need to add these to the code. The code change is fairly simple and there may be other implementations that have done the same thing, since this order to ship process is quite common to automate.

Message place holder