... If however you can isolate a specific event on an underlying data field or view that needs to always force an update on an another view, you could create an even to trap that condition and force the refresh -... Hi @ShawnBerk Can an event force a refresh? What is the command for that? Our IT team is trying to program a small event that changes a value in a custom field after a Copy Part (diferred event) and we would like to force a refresh after … but do not know how. Thanks in advance for your help!
Hi Iker, When adding Alternate Components, you can select “Include During MRP” which I believe will begin planning for your new parts as the SOH of the old part depletes? Cheers, Wade Hi Wade @ConMan No, it will not. We are using this functionality and works only in the following way: It will plan usage of the Alternate Component (only if the Alternate Component has Qty On Hand, that is, if you already have it in-house ), when shortage of the main Part = negative projected on hand of main part. That is, if tyou have Qty On Hand of main Part and Alternate → it will plan to use the main part (though will take into account the Qty On Hand of the Alternate for future Supply of the main Part, = you will buy less of the main Part). If you do not have Qty On Hand of the Alternate → it will do nothing, and never ask to buy it If you fall into shortage of the main Part, and you have Qty On Hand of Alternate Part, it will suggest using it. And will plan to purchase the main Part for future dem
Hi Ikerrari, I manage the Phase In/Out of all our product changes, and what I choose to do is review changing demands on a weekly basis and move the Phase In/Out dates accordingly to ensure a smooth transition and runout of old parts. However, if you are in an environment where multiple changes occur regularly and inevitably overlap, this would make managing changes via Phase In/Out dates virtually impossible. Perhaps an idea would be to add your new parts as alternates to the old parts prior to uprevving the structure and making the change permanent. This way, MRP can plan for your new parts whilst the SOH of your old parts is depleted. Then, when you finally runout the old part, simply up-rev to begin using the new part which should already be in stock based on MRP demand? Cheers, Wade Hi Wade @ConMan Great! Thank for your reply and support. We did a small audit last week. In the first 6 months of 2022, we have launched 101 changes, affecting 301 structures … 29 of those 101 change
Hi Ikerrari, From your scenario above, I don’t think using Alternate Parts is the right thing to do. Once you Phase In a new revision with new parts, MRP will plan to this immediately, and with SOH of the new part MRP will ignore the residual SOH which is now your Alternate Part. I would be using the Phase In/Out date in the Inventory Part for the Product Structure to manage when you want to Phase In the new revision with the new parts. This way you can continue to use up your old parts but MRP can still plan to buy the new ones. Once all SOH of the old part is gone, you can Phase In your new revision and begin using it. This is how I manage runout of old parts/introduction of new parts when making product changes. Cheers, Wade Hi Wade @ConMan , Thanks for your reply. Yes, I see your point. And this is also being discussed in-house. There are cases when this ramp down of “old parts” and ramp up of the new substitue, takes several weeks/months to be completed. During this transition
Hi, In MRP, the logic works as Jane describes it, so for the primary component, MRP engine checks: Does available inventory onhand cover the gross requirement? If no or “to some extent” then check if there are any open supply order for the primary component that can be applied in the netting logic If open supply does not cover the temporary net requirement check if alternate component can be used in the netting logic If there is excess onhand for the alternate component then plan for it :-) Net requirement will be reduced. If there is still a net requirement at this stage, do the lot sizing and create SO/PO Requisitions (for the primary component of course). I should mention that MRP figures out in which order it should perform the netting. As a general rule the alternate component(s) are processed prior the primary component. And yes Production Schedules differ from Shop Order and MRP in this area. Production Schedules was kind of designed for “use up” of alternate component prio
Hi, For what it’s worth, these are my thoughts. You can set the Phase In/Out date into the future, and when you’re ready to Phase In, you can bring the dates back as desired or let it Phase Out/In naturally. Also, you could set the new MS to Plannable so it can continue to plan against the structure as is. For the reason above, I wouldn’t be a fan of the Buildable status setting the Phase In, we use the Plannable status whilst processes are being updated prior to being made Buildable, therefore we need the Phase In date to be what we want it to be, not when the status is Buildable. Cheers, Wade Hi Wade, Thanks for your inputs. Appreciated. We do not use the Plannable status on MS, and will have a look. Best regards, Iker A
Ok, I will repost it as an idea.
@ikerarri As mentioned, MRP can currently only consider available stock of the alternate component, not open supplies. Also, the replacement to alternate component on the shop order must be done manually (easiest to use the “Replace All to Alternate Components” from the header). Please consider requesting this to be implemented for a future IFS release in the Idea section of the community! Ok, thanks! Re-posted as IDEA.
@ikerarri thanks for the info on where to change, my error is complaining about parent revision, if i understand correctly, the rule is children should have revision dates later than parent. what is the rule of thumb here to follow, can you help me understand. is it parent product structure part vs child product structure part number or just change revision on component’s ‘Revision’ tab? thanks Children should have phase-in dates older than parent phase-in date. You cannot build a parent with children that do not exist at a given date ;-) First childrenThen parentYou can define phase-in date by editing it in the Revision tab of the Inventory Part Hope it helps, Iker A
@ikerarri @william.klotz @ShawnBerk We don't use Product Structure here often, encounter this error for the first time, when trying to duplicate structure from one site to another. Product Structure Header was created a month agao and now when the user is trying to add components, we are getting following error. I see @ikerarri mention that we need to change phase in date in inventory, will it be product structure (header) that need to be updated or its components? any sql/script or screenshot will be helpful. Bundle of thanks. we are using IFS8. The phase in needs to be managed in the Revisions Tab in the Inventory part. Regards, Ikerarri
Hi @Abdul Interested in the same topic. We have a similar situation where we would like to use two different Alternate Structures (Purchase type). But the Purchase Order will always refer to Alternate Structure * (and never let us choose any different Alternate Structure). How did you solve your need? Can you explain? Any ideas on how to use two different Alternate Structures (Purchase type)?Thnaks and regards, Iker A
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.
