Appreciate your responses. I quickly realized this morning that I did not specify(only tagged) that we are on Apps 10. We will not be on cloud for another yearish. It appears those API’s are not available to us. API Explorer - shopfloor% filter
Thanks for the clarification. Any thoughts on how it was able to be set like that in the first place(with a statement and validation box checked)? We’ve only had IFS consultants on premises for our installation of the maintenance module. My guess is that this is set as shown above at other companies as well.
I have found the line of code that is not being addressed. Problem originates on Line 15821 of SHOP_ORDER_OPERATION_APIVariable do_not_close is declared do_not_close_ VARCHAR2(10); A debug session reveals that do_not_close is not part of attr_ before the binding, or after. Line 15967 variable do_not_close_ is bound as:do_not_close_ := Client_SYS.Cut_Item_Value('DO_NOT_CLOSE', attr_); Passing do_not_close_ as NULL to SHOP_ORDER_OPERATION_LIST_API.Verify_Status will default to FALSE on line 2625 thus return Oper_Status_Code_API.DB_CLOSED Code then continues - on Shop_order_operation_api.Update___ line 17189 Since op_closed_db_ was returned closed from above, and clocking_seq is null because this is a Qty only report, and clockings do exist, as the operation is still in process - causing this was hitting trigger the Stop_operation call everytime as seen below. IF ((newrec_.oper_status_code = op_closed_db
The clocking is probably stopped since the operations becomes closed as a result of reporting full or higher quantity on them. Maybe integration can be rewritten to first report the operation quantity (corresponding to approve) and then sending the Close Operation as false to make sure the operation remain open. Then perform the receive (without using Auto Report)? This seems like it should be an option that we’re just over looking. And just for clarity - the operation does not close, but the clockings do stop.The Receive Part API has 2 parameters regarding Operations.1 is Auto Report( The checkbox on the receive Shop Order screen) which we are sending as True.The other is Auto Close which we are sending as False.
Your understanding of my request is correct. This is too bad, it seams like a lost opportunity to assist in the handling of quality issues found in a manufacturing environment.
I meant to say the Handling unit I wish to add contains the same Part No and Lot No as the existing MRB case.
Thanks Rifki, this is exactly the problem. Your explanation of the “Virtuals” was very informative. We’ve since been able to POST a status change. We have yet to be able to issue a line item to a Material Requisition, but I believe we’re on the right track. Any chance there’s a way to view all the API calls at once? VS looking at each set in the API Explorer? I feel like this would be beneficial when trying to find certain calls. Thanks for taking the time to post!
I checked, and we are not using the Sign Off Requirements. We have raised a case as it appears to be happening every time, as was raised to some to the RnD. Thank you for the explanation!
We do not have customization done to the maintenance portion of IFS.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
