Skip to main content

We have a few nodes we no longer want to use - but if we try to delete we get a message saying: 

 

I can not find an option for flagging a node as obsolete.

Is there a sure-fire way to make sure a node can not be used?

Generally, you cannot delete something that is reference data for transactions.  In this case, you have GL distributions linked to the nodes so it would create problems deleting the nodes and you were properly warned by the Alliance application.

I am not sure there is a way to make the node unavailable for use by the users but am checking on this aspect with others.  Would I be correct that the users have access to a parent node with access to descendants thus they still have access though not explicitly granted in the user node security?

 

I am thinking of making a dummy node at a top level, make the nodes you do not want a child of that node so this way they will not be able use descendants and of course remove any reference to the node in the employees security as you will not assign the dummy node to any one.

Of course anyone with bypass security or bypass node security enabled will still be able to access it.  Presumably you have moved all the customers and other entities out of the node to not use further.

 

 

 


This is a pretty good suggestion, Phil. Thanks!

 


HI Bjørn,

I have confirmation there is no functionality in the Alliance application to remove or make a node obsolete once there is any reference to it in other areas like warehouses, orders, employees, etc.  Once a transaction has occurred, it must be available for data integrity down the road which is why DELETE is prevented.

At this point, the only way you can achieve actually not making the node available to users by the system without a code change customization (might be a large customization) is to:

  1. Create a new top level dummy node to use as a parent parking node
  2. Ensure none of the warehouses/employees/etc. are linked to the desired node to disable
  3. Change the parent node of the node to disable to the one created in the first step.
  4. Ensure no users are assigned node security access to the node created in the first step.

 


Hi Phil - we have deployed this - works really well


Reply