How To Fix FICUSTOM275 - Address &1 became leaf node when its subordinate nodes were moved

FICUSTOM275 - Overview

• Message type: E = Error

• Message class: FICUSTOM - Customizable Messages for Funds Management

• Message number: 275

• Message text: Address &1 became leaf node when its subordinate nodes were moved

What causes this issue?

Moving or deleting a node to under a new higher-level account assignment
can go against the rules for budget addresses that were defined for
transaction <LS>Create/Assign Subhierarchy_ID</> (FMHIE_HIEID).
The list for budget addresses or posting addresses can become invalid
due to reason &V2&.
<ZH>Reason 1: Inconsistency in Posting Address List</>
You defined the following rules: "All Account Assignments in the
Multi-Level BS are Valid Posting Addresses" and "Only Account
Assignments at End Node Level in the Multi-Level BS are valid Posting
Addresses?. Due to moving the node, inconsistencies have occurred in the
list of posting addresses as the hitherto higher-level node &V1& has
become an end node. Through this change, the node &V1& can now be posted
to, but may not be able to be maintained in the posting address list.
<ZH>Reason 2: Inconsistency in the Budget Address List</>
You have defined the following rules: "All Accounts Assignments Except
End Nodes are Valid Budget Addresses" and "All Accounts Assignments in
the Multi-Level BS are Valid Posting Addresses". Due to moving the node,
inconsistencies have occurred in the budget address list as the hitherto
higher-level account assignment &V1& has become an end node and as such
can no longer be a budget address, however is still entered in the list
of budget addresses.
<ZH>Grund 3: Inconsistency in the budget address and posting address
list</>
You have defined the following rules: "All Account Assignments Except
End Nodes are Valid Budget Addresses". Moving the node has caused
inconsistencies to occur in the budget address list as the hitherto
higher-level account assignment &V1& has become an end node and as such
can no longer be a budget address, but it is still in the list of budget
addresses.
Moving the node has caused inconsistencies to occur in the posting
address list as the hitherto higher-level account assignment &V1& has
become an end node. The change means the node &V1& can be posted to, but
may not be in the list of posting addresses to be maintained.

System Response

Processing is terminated.

How to fix this error?

You can correct the error in one of the following ways:
Delete or enhance the budget address list (transaction FMBSBO) or the
posting address list (FMBSPO) with the account assignment &V1&.
Change the definition rule for budget addresses or postings addresses in
transaction <LS>Create/Assign Subhierarchy_ID </>(FMHIE_HIEID).
Set this message to a warning, information, or ignore if you want to
override this message in Customzing under <LS>Funds Management
Government -> Basic Settings -> Change Message Control</>. However, when
doing this, note that overriding the message can cause inconsistencies
to occur in the multi-level budget structure.

Procedure for System Administrators

Error message extract from SAP system. Copyright SAP SE.

Smart SAP Assistant

• What is the cause and solution for SAP error message FICUSTOM275 - Address &1 became leaf node when its subordinate nodes were moved ?

  The SAP error message FICUSTOM275 indicates that an address (in this case, identified by &1) has become a "leaf node" because its subordinate nodes have been moved. This typically occurs in the context of address management within SAP, particularly when dealing with hierarchical structures of addresses, such as in customer or vendor master data.
  
  Cause:
  
  Hierarchical Structure Changes: The error usually arises when there are changes in the hierarchical structure of addresses. For example, if subordinate addresses (like branches or locations) are moved to a different parent address, the original parent address may no longer have any subordinate nodes, thus becoming a leaf node.
  Data Integrity Issues: This can also happen if there are inconsistencies or integrity issues in the address data, such as incorrect relationships between parent and child addresses.
  
  
  Solution:
  
  Review Address Hierarchy: Check the address hierarchy to ensure that the relationships between parent and subordinate addresses are correctly defined. You may need