Created a ticket for this. OLMIS-5085

Created a ticket for this. OLMIS-5085

Thanks! I have struggled with this section of the documentation a bit. Is this somehow generated into a javadoc? updating it as follows: /** * Calculates Adjusted Consumption (N) value and retur...

Thanks!
I have struggled with this section of the documentation a bit. Is this somehow generated into a javadoc?
updating it as follows:

/**
   * Calculates Adjusted Consumption (N) value and returns it.
   * - When additionalQuantityRequired field is not in template,
   * The formula used is N = RoundUp(C * ((M * 30) / ((M * 30) - X)))
   * If non-stockout days is zero the formula is N = C
   * - When additionalQuantityRequired column is present in the template,
   * The formula used is N = (RoundUp(C * ((M * 30) / ((M * 30) - X))) + additionalQuantityRequired)
   * C = Total Consumed Quantity
   * M = Months in the period (integer)
   * N = Adjusted Consumption
   * X = Total Stockout Days
   */


If javadoc is going to be generated, I may be able to use <p> tags and spacing the different conditions may make them appear better. does the following seem better?

 /**
   * Calculates Adjusted Consumption (N) value and returns it.
   * <p>
   *   The calculations used can be different depending on the visibility of
   *   Additional Quantity Required column.
   * </p>
   * 
   * <p>
   *   When additionalQuantityRequired field is not in template,
   *   The formula used is N = RoundUp(C * ((M * 30) / ((M * 30) - X)))
   *   If non-stockout days is zero the formula is N = C
   * </p>
   * 
   * <p>
   *   When additionalQuantityRequired column is present in the template,
   *   The formula used is N = (RoundUp(C * ((M * 30) / ((M * 30) - X))) + Z)
   *   If non-stockout days is zero the formula is N = C + Z
   * </p>
   * 
   * <p>
   *   C = Total Consumed Quantity
   *   M = Months in the period (integer)
   *   N = Adjusted Consumption
   *   X = Total Stockout Days
   *   Z = Additional Quantity Required
   * </p>
   */
Yes, there is a message for this key. This is a key that I reused from other validations.

Yes, there is a message for this key. This is a key that I reused from other validations.

OLMIS-4966: Added additional column on requisition template.
OLMIS-4966: Added additional column on requisition template.
OLMIS-4966: Add additional column on requisition template called additionalQuantityRequired.
OLMIS-4966: Add additional column on requisition template called additionalQuantityRequired.
Seems to test the opposite of what the name implies.

Seems to test the opposite of what the name implies.

does the if condition test read, queryParams contains programId but does not contain facilityId? if so the error message seems to not match.

does the if condition test read, queryParams contains programId but does not contain facilityId? if so the error message seems to not match.

This one was a great catch. The code was not returning 403 even though the RAML specifies it. It was returning 400. I am working on this.

This one was a great catch. The code was not returning 403 even though the RAML specifies it. It was returning 400. I am working on this.

Yes, It is a challenge. How does this look? ReleasableBatchDto { ... List<ReleasableRequisitionDto> requisitionsToRelease; }

Yes, It is a challenge. How does this look?

ReleasableBatchDto 
{
   ...
   List<ReleasableRequisitionDto> requisitionsToRelease;
}
It looks like the createdDate time stamp for status_changes is set on prePersist. This method call (releaseWithoutOrder) and the corresponding test do not trigger the persist calls. Because of this...

It looks like the createdDate time stamp for status_changes is set on prePersist. This method call (releaseWithoutOrder) and the corresponding test do not trigger the persist calls. Because of this, I do not think testing the timestamp is necessary here.

Yes, the only reason the requisition processing status is added is a recommendation from spec review. The return values are currently not being used in the frontend. https://review.openlmis.org/cr...

Yes, the only reason the requisition processing status is added is a recommendation from spec review. The return values are currently not being used in the frontend.

https://review.openlmis.org/cru/FEOLMIS-3102#c18584

Currently, when the processing status has the error, errors would be populated, if the order succeeded, the requisitions would be listed. Not both at the same time.

Yes. will do this.

Yes. will do this.

I was going to accept your proposal and change that to RequisitionReleaseDto. Other potentials names include: RequisitionReleaseBatchDto ReleaseBatchDto

I was going to accept your proposal and change that to RequisitionReleaseDto. Other potentials names include:

RequisitionReleaseBatchDto
ReleaseBatchDto

Yes, if one or more errors found, the whole batch will fail.

Yes, if one or more errors found, the whole batch will fail.

How about I rename this to "ReleasableRequisitionDto"?

How about I rename this to "ReleasableRequisitionDto"?

OLMIS-4865: release requisition without order
OLMIS-4865: release requisition without order
OLMIS-4958: create a consolidated api for releasing requisitions with or without order.
OLMIS-4958: create a consolidated api for releasing requisitions with or without order.
agreed. I have updated the tests.

agreed. I have updated the tests.

awesome. will do it.

awesome. will do it.

http://build.openlmis.org/job/OpenLMIS-fulfillment-pipeline/job/master/lastSuccessfulBuild/artifact/build/resources/main/api-definition.html#api_orders__id__retry_get The API returns true or false...

http://build.openlmis.org/job/OpenLMIS-fulfillment-pipeline/job/master/lastSuccessfulBuild/artifact/build/resources/main/api-definition.html#api_orders__id__retry_get

The API returns true or false if the retry succeded or failed. However, in other cases, it can also return 400 or 403 responses. in those cases, I want to the code to display what is in the description section of the response. Not failed transfer.

These two tests test the two different conditions. 1. when the response is false. and 2. when response is 400 error. In both cases, we know the retry was not successful. but for different reasons.

I will change the it('') section to make sure the second one describes 400 response.

Thanks for catching that.