Raises the question: how redundant is that code.
Which also raises the question: how important is that in our times.
I personally always liked it to factor out common code into "company libraries".
But when the SOAP opera started, I realized that no one is putting the generated interface code into a library. So that everyone can get it from a repository.
Instead the regenerated the interface for every department that wanted access to the service. And: they use a naming schema fitting to the project that wants the interface. As in packe names fitting to the client and not the service.
With the result, that I was in a project, where we accessed two different methods of the service, and got the SOAP/WSDL based interface generated two times with different package names.
The two guys responsible for the service, likely did that intentional, to make them look important.
Anyway: having the "same object/class" with two different package names in the same code base, makes them incompatible. So we needed to write a conversion layer, that converted the incoming objects into our owns.
Result: we had half a dozen classes three times. Once our own implementation, which we persisted in our own DBs ... (also already nonsense), and two versions from the service: with the same attributes, in the same order and the same methods.