It is a really good idea. Currently, all the shipment integrations
> Hi,
>
> Recently, discussion around moving third party integrations has been
> initiated again on dev mailing list thread <
>
https://lists.apache.org/thread.html/rf7967b26b89d753388ccee364643f502c72e781da54fe6d5aca1577f@%3Cdev.ofbiz.apache.org%3E>
> and was also discussed in past on dev mailing list thread <
>
https://lists.apache.org/thread.html/e2a2b5598fb4314062beca47e0522434852d0189e888e36852b5a6cd@%3Cdev.ofbiz.apache.org%3E>.
> When reviewing third party shipping integration in this context, I noticed
> that some of the shipping integration services (example, upsShipConfirm,
> fedexShipRequest, etc.) are hard coded at places in product and order
> components and in shipment workflow in facility application. There could be
> some other such occurrences as well. Ideally these third party services
> needs to be configurations and to be able to move these shipping
> integrations out of applications to plugins some refactoring is needed so
> as to not loose any existing support in OFBIz applications.
>
> We do have ProductStoreShipmentMeth entity for configurations but it is
> more specific to detailed shipment method level configurations rather than
> carrier level configurations. We also have carrier level shipping gateway
> configuration entities like ShipmentGatewayUPS, etc. But again these are
> more specific to store connectivity configurations. I feel that we need
> more like a ProductStorePaymentSettings entity to configure various
> possible integration services (like rate service, request label service,
> address verification service, etc.) offered by these third party logistic
> services.
>
> I propose to introduce a new entity “ProductStoreShipmentSettings” to
> configure available shipping gateway services for shipping carriers at
> product store level. To begin with the entity could have following fields,
> 1. productStoreId (pk)
> 2. carrierPartyId (pk)
> 3. shipmentServiceEnumId (pk)
> 4. shipmentService
> 5. shipmentGatewayConfigId (Ideally this field should become party of this
> new entity, though it is currently supported in ProductStoreShipmentMeth
> entity)
>
> The above change would enable us to refactor these hardcoded reference to
> make them configurable and be able to move these integrations to plugins
> without loosing any available support in applications.
>
> Looking forward to suggestions and feedback.
>
> Thanks.
> Mridul Pathak
Locked
