Cui Pengfei

No, I think we can close it now.

No, I think we can close it now.

Right now, events are write-only. Its processing results allow read. I am not sure if we want to allow reading on events directly, Josh Zamor

Right now, events are write-only.
Its processing results allow read.
I am not sure if we want to allow reading on events directly, Josh Zamor

Josh Zamor Earlier today we mentioned that if we make "/api/stockEvents" support multiple orderables, then we will not need "/api/physicalInventories" anymore. I just realized that may not be true...

Josh Zamor
Earlier today we mentioned that if we make "/api/stockEvents" support multiple orderables, then we will not need "/api/physicalInventories" anymore.

I just realized that may not be true.

When some one posts to "/api/physicalInventories", we essentially do 3 things:
1. turn physical inventory into event, then let event processor process the event.
2. save the physical inventory itself. (it points to the event created because of the physical inventory)
3. delete physical inventory draft(if it exists)

The record saved in step 2 is not used anywhere, for now.
It's saved in case in the future someone may want to view historical physical inventories. Like "GET /api/physicalInventories?program=x&facility=y".

If we still think in the future someone may want to view historical physical inventories, then I think we should keep "/api/physicalInventories" as its own resource.

https://test.openlmis.org/stockmanagement/docs/#!/default/post_api_stockEventsRevised
stock events api redesign, one event could include multiple orderables
stock events api redesign, one event could include multiple orderables
It is a string, with a regex, at the top of this file.

It is a string, with a regex, at the top of this file.

This is added because the front end needs to display existing soh.

This is added because the front end needs to display existing soh.

updated

updated

This is added, because the front end needs to display physical inventory status: not started yet, in progress, etc.

This is added, because the front end needs to display physical inventory status: not started yet, in progress, etc.

API can be called with a smaller set of data. only quantity and orderable id are required. We just used the same json schema for get draft and post draft.

API can be called with a smaller set of data. only quantity and orderable id are required.

We just used the same json schema for get draft and post draft.

just added localized message for 400 and 403, will push.

just added localized message for 400 and 403, will push.

Submission of a physical inventory gets turned into stock events/cards/line items, we are returning UUID of the physical inventory itself here. I was not sure what's a proper schema for UUIDs, sho...

Submission of a physical inventory gets turned into stock events/cards/line items, we are returning UUID of the physical inventory itself here.

I was not sure what's a proper schema for UUIDs, should it just be string?

I think when we add support for lot, lots of APIs will be changed, not only this one. I think there will be an analysis on what should be changed in what way.

I think when we add support for lot, lots of APIs will be changed, not only this one.
I think there will be an analysis on what should be changed in what way.

It's easier to see in swagger: https://test.openlmis.org/stockmanagement/docs/#!/default/get_api_physicalInventories_draft https://test.openlmis.org/stockmanagement/docs/#!/default/post_api_physi...
APIs for: save draft, get draft, and submit physical inventory
APIs for: save draft, get draft, and submit physical inventory
SHIYU
renamed in commit: https://github.com/OpenLMIS/openlmis-stockmanagement/commit/59fe5b2c09ecca2102aef23e95adee1b5feb78d6
Yes. It'll look something like "2017-02-28T03:12:36.427Z"

Yes. It'll look something like "2017-02-28T03:12:36.427Z"

Josh Zamor which line were you referring to? fisheye is showing me all of your comments at the top of the page.

Josh Zamor which line were you referring to? fisheye is showing me all of your comments at the top of the page.

I think it's a good idea to track things in jira. SHIYU Mary Jo

I think it's a good idea to track things in jira.

SHIYU Mary Jo

Yes. And the other one called balance adjustment is used when a user is doing physical inventory check and found out that the stock on hand is same as what the system is already recording.

Yes.

And the other one called balance adjustment is used when a user is doing physical inventory check and found out that the stock on hand is same as what the system is already recording.

Mary Jo Should we create a jira ticket for this, then elaborate and prioritize it?

Mary Jo Should we create a jira ticket for this, then elaborate and prioritize it?

If there is a reason id within a json body, the added/subtracted will be inferred from the reason. If there is a source id, then it's receiving, so added. If there is a destination id, then it's ...

If there is a reason id within a json body, the added/subtracted will be inferred from the reason.

If there is a source id, then it's receiving, so added.

If there is a destination id, then it's issuing, so subtracted.

"programId": "dce17f2e-af3e-40ad-8e00-3496adef44c3", "facilityId": "176c4276-1fb1-4507-8ad2-cdfba0f47445", "orderableId": "d602d0c6-4052-456c-8ccd-61b4ad77bece", "occurredDate": "2017-02-06T10:00:0...

"programId": "dce17f2e-af3e-40ad-8e00-3496adef44c3",
"facilityId": "176c4276-1fb1-4507-8ad2-cdfba0f47445",
"orderableId": "d602d0c6-4052-456c-8ccd-61b4ad77bece",
"occurredDate": "2017-02-06T10:00:00.000Z",

"sourceId":"087e81f6-a74d-4bba-9d01-16e0d64e9609",

"quantity": 100,
"signature": "srmanager"

Put the above lines in {}, that'll do receive 100. (fisheye does not let me post json)

if you need to use different reasons or difference source/destinations, please refer here:
https://github.com/OpenLMIS/openlmis-stockmanagement/tree/master/demo-data

That's a good idea. Json schema does allow reference to another schema by url like: "$ref": "http://xyz.com/schema/someModel#" I'll look into that.

That's a good idea.
Json schema does allow reference to another schema by url like: "$ref": "http://xyz.com/schema/someModel#"
I'll look into that.

Yes, that is correct. When this json schema was first written(before spring festival), I was thinking we are just going to output whatever we saved in the DB, which includes destination id. Then ...

Yes, that is correct.

When this json schema was first written(before spring festival), I was thinking we are just going to output whatever we saved in the DB, which includes destination id.

Then when we were implementing the end point, I thought the front end will need to display text, if we only provide ids, the front end would have to ask ref data service for details of facility, program and orderable. That's why I replace destination id with a whole destination object.

Currently, each reason has these 5 attributes: name, description, reasonCategory, reasonType, isFreeTextAllowed name and description are self explanatory. reason type indicates if it's credit or ...

Currently, each reason has these 5 attributes:
name,
description,
reasonCategory,
reasonType,
isFreeTextAllowed

name and description are self explanatory.

reason type indicates if it's credit or debit.

reason category is first added for UI to filter what is shown to end users.
Then in JIRA ticket 1633, there are added validation rules regarding reason category.
For example, when a user is doing adjustment, they can only use reasons that have category as ADJUSTMENT.
When a user is doing receiving or issuing, they must use reasons that have category AD_HOC.