-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implemented: schema for shipment, defined action to fetch the shipments, and added transformation rule(#2vd6xty) #14
base: main
Are you sure you want to change the base?
Conversation
…n the PR(#2vd6xty)
…relation between order and shipment(#2vd6xty)
…e some formatting(#2vd6xty)
const query = { | ||
"inputFields": { | ||
"destinationFacilityId": payload.facilityId, | ||
"statusId": "PURCH_SHIP_SHIPPED", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are allowing to fetch only shipped and incoming shipments here. I would suggest making it configurable along with the following improvements:
We should define shipment status enumerations for apps (created, shipped...) and perform mapping in the package. This way package could easily take care of the different status values of different backend servers. The app query will be static for different backends having a defined status and the package does the magic.
For incoming/outgoing shipment conditions, I would suggest 2 possible solutions:
- We should have separate methods for incoming and outgoing shipments.
- We should have a payload parameter, that identifies if the query is for incoming/outgoing shipment. If we consider handling with payload, we need to add these conditions to the query only when we receive certain parameters with payload.
For example, we identify a field shipmentType with values incoming/outgoing. If we do not receive any value we fetch all shipments else add
"shipmentTypeId_fld0_value": "INCOMING_SHIPMENT",
"shipmentTypeId_fld0_op": "equals",
"shipmentTypeId_fld0_grp": "1",
"parentTypeId_fld0_value": "INCOMING_SHIPMENT",
"parentTypeId_fld0_op": "equals",
"parentTypeId_fld0_grp": "2",
This way we are abstracting applications from server details. The app needs incoming shipments, different backends may have different data models. If we define these conditions in apps, we may diverge from the bodiless approach and have to perform workarounds when switching between backends.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed with @adityasharma7 Sir and @dt2patel Sir, we will define two separate methods for incoming and outgoing shipments.
Also will create enums for shipment type and shipment status in oms package.
Related Issues
Closes #30
Short Description and Why It's Useful
Screenshots of Visual Changes before/after (If There Are Any)
Contribution and Currently Important Rules Acceptance