A request to manage suppliers and customers separately can tempt a developer to create two unrelated partner tables. But a business can both buy from and sell to the same counterparty. Duplicating that counterparty raises an immediate question: which copy owns its earlier documents? Reviewing this project's requests and role implementation reinforced a distinction I find useful in many applications. Dividing a working list is not the same as dividing the identity of the person or organization represented by it.
A role describes a relationship and direction
The preserved code has roles for customer, supplier, both and awaiting classification. A purchasing document accepts a partner with a compatible purchasing role; a sales document uses the other direction. The interface can therefore reduce irrelevant choices while preserving one identifier for a counterparty with both roles. Earlier records and current details do not need to become disconnected copies merely because two menus present different subsets.
Assigning every partner to both roles would remove the value of that distinction. Classification should reflect a relationship that has actually been established. Similar names or brands are not sufficient evidence for a purchasing role. The archived requests include corrections to the distinction between selling counterparts and suppliers. I would retain such decisions as reviewed classifications while preserving the original source and the documents that led to them, rather than rewriting those sources to match today's convenient categories.
Carry the context into both selection and validation
A shared partner picker can behave differently according to the document being written. If only the interface filters suppliers while the server accepts any partner, another route can save an incompatible selection. If only the server enforces the rule, a person may select a visibly offered partner and then encounter an unexplained rejection. Search and write validation need to express the same role contract.
Unclassified partners also need an ordinary resolution path. Simply hiding them can lead staff to register an existing business again. A person should be able to find the existing identity and, with appropriate authority, confirm its role or leave it awaiting review. Creating a partner and adding a role to an existing partner are different actions. Distinct button labels help preserve that difference, especially when the user is trying to finish a document rather than reorganize a master list.
A current role must not rewrite old transactions
Reclassifying a partner as a supplier should not turn an earlier sale into a purchase. Document kind, counterparty identifier and recorded amounts describe a past event. Current classification mainly supports future selection and administration. I would keep those responsibilities separate. Disabling a role also needs a deliberate policy for reading and reprinting old documents; removing a current option should not make historical evidence inaccessible.
Role corrections should retain their previous values and reasons. They should also remain distinct from merging duplicate identities. A merge can affect every linked document and source identifier, making it much broader than changing a role checkbox. Automatically performing that broader operation to tidy a list may leave a future operator unable to explain why unrelated history now appears under a particular partner. A clean interface is not sufficient evidence for an identity merge.
The same principle applies beyond ERP
Members and clients, customers and collaborators can all be different roles of the same underlying party. A shared identity with role-specific views can reduce repeated entry and preserve history. However, separate legal entities with matching names should remain separate. The reusable principle is to separate identity verification from role selection, not to combine every similar-looking record into one.
For review, use synthetic partners with one role, both roles, an unresolved role and a name shared by another entity. Follow search, registration, role correction and historical detail. Identify which values change and which records must remain intact. This article comes from selected requests, preserved role code and dated records; I did not alter the actual partner classification. A well-separated interface depends on a structure that can present different working views without losing the continuity of the counterparty's records.