Hello IFS Community!In this workflow we have a 4-Level Intersite PO:What we call “the Order Desk” (L1) The Product Line in USA (L2) The Product Line in Canada (L3) The manufacturing facility (L4)Going into the details as to why the PO matrix is structured that way would be going on a tangent, and to make this post as short as possible (is likely going to be long anyways as the problem is not easy to be described) I’m going to concentrate on our issue.Take this PO for example (where you can see the 4 levels stacked up nicely in the Supply Chain Customer Order Analysis screen)Our issue can be summed up like this: after releasing a L1 CO, IFS goes and automatically creates subsequent Level 2 CO and PO, Level 3 CO and PO and Level 4 CO and Shop Order (where the component really gets manufactured) for us. After that, eventually the work gets done, Shop Order is Closed, items are shipped to customer, the Level 4 CO Invoiced, etc, etc. So far so good.And then the problem looms: in one (and o
Hi Friends!I have a simple question (I guess) related to tracing…If I have a call to the Trace_Sys.Message inside a Custom Event Action. How can I see it?
Hello Community!I have the following Code-- In this block we perform the actual change.DECLARE PARTTYPEERROR EXCEPTION; [SOME_OTHER_VARIABLES]BEGIN FOR sale_part_to_update_rec IN ( [SOME_SQL_TO_PERFORM_LOOP] ) LOOP p0_ := NULL; p1_ := sale_part_to_update_rec.OBJID; p2_ := sale_part_to_update_rec.OBJVERSION; client_sys.add_to_attr(name_ => 'SOURCING_OPTION', value_ => sale_part_to_update_rec.SOURCING_OPTION, attr_ => p3_); client_sys.add_to_attr(name_ => 'RULE_ID', value_ => '', attr_ => p3_); p4_ := 'DO'; BEGIN IFSAPP.SALES_PART_API.MODIFY__( p0_ , p1_ , p2_ , p3_ , p4_ ); COMMIT; EXCEPTION WHEN PARTTYPEERROR THEN [MY_ERROR_HANDLING_CODE] END; END LOOP;END;I have noticed that even when the IFSAPP.SALES_PART_API.MODIFY code I execute results in an PARTTYPEERROR Exception...… The block to handle that type of errors is never invoked. The exception
Today I was trying to test a technique to run a MODIFY__() PROCEDURE that will affect a bunch of Inventory Parts in order to update the Safety Lead Time Value. The code I wrote was like this. -- Use IFS API repeatedly to perform some action-- (In this case updating Safety Lead Time on Inventory Parts)DECLARE -- p0 -> __lsResult p0_ VARCHAR2(32000) := NULL; -- p1 -> __sObjid p1_ VARCHAR2(32000) := 'AAAWhqAAGAAHl+JAAO'; -- p2 -> __lsObjversion p2_ VARCHAR2(32000) := '20240110114450'; -- p3 -> __lsAttr p3_ VARCHAR2(32000) := 'SAFETY_LEAD_TIME'||chr(31)||'5'||chr(30); -- p4 -> __sAction p4_ VARCHAR2(32000) := 'DO'; sql_stmt VARCHAR2(1024); tbl_count number;BEGIN FOR inventory_part_to_update_rec IN ( SELECT INVENTORY_PART_PLANNING.PART_NO, INVENTORY_PART_PLANNING.OBJID, INVENTORY_PART_PLANNING.OBJVERSION FROM PRD_08 INNER JOIN INVENTORY_PART_PLANNING ON PRD_08.PART_NO = INVENTORY_PART_PLANNING.PART_NO WHERE
I’m a bit confused with the functional differences between 2 fields in the different Engineering Part Revision Forms. One is “Eng Rev” (or Eng Revision) and the other one is just “Rev No” (or Revision No) In IFS Explorer the first field is described as “The engineering part revision for the selected part. This field cannot be modified. This field is for information only and affects nothing else in the system. “The second one (Rev No) is described as “The internal counter used to keep track of all revisions for a part. For each new revision, the counter is incremented by one. This is used to correctly order part revisions in forms and reports. This field cannot be updated manually.” … yet conceptually I can’t wrap my head around of the difference or how are they supposed to be used in different ways. Anybody can explain this for me? Thanks!
Hello IFS Community! I’m assessing a strategy for a legacy ERP migration into a PRODUCTION IFS APPS 10 (UPD16). This is a multi-tenant instance (many companies are running on this IFS instance). There is already one company operational and I am migrating company #2.My question is this: we are considering two strategiesMigrate this new company (let’s call it, company “A”) into PRODUCTION where the current company (company “B”) is operational. Do the migration and QA work directly in PROD. Once the GO-NO GO decision is made (if GO) then just start using PROD with no further delays. In this approach there is no freeze period for company “B” Migrate this new company in a staging environment that we will clone off PRODUCTION (so all of company’s “B” data is there), freeze PROD during migration (tell users of company “B” site is off-limits for now). Do the migration and QA work there (in staging). Once the GO-NO GO decision is made (if GO) then clone back the staging into PROD and unfreeze
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.