both documents are nearly identical and I wasn't sure what would be the better route, create a separate endpoint for both or parametrize the one existing endpoint.
The difference is that lot, binLocation and expirationDate are empty on the template and quantity on the template is RequsitionItem.quantity.

I chose to add a boolean parameter template for the same endpoint but I am open to your criticism if this approach is not a correct one.

I was really confused by this. I figured the template would be a completely blank template, but I went back to the ticket and now I'm understanding it a bit more. I don't think we want to pass a boolean parameter for this. This should be something derived - each line knows whether it has picklist items associated with it or not.

PickList -> Picklist

I get that this might be confusing and not seem all that important. But when we're talking about a single resource, we should make sure not to over-capitalize. This goes for other WMS-specific terms like putaway as well. In case it's not clear, it should be Putaway, not PutAway. We should be consistent across the application but I'm not sure how to make it more clear and intuitive. Any thoughts on how we can do that? Maybe a glossary?

I was really confused by this. I figured the template would be a completely blank template, but I went back to the ticket and now I'm understanding it a bit more. I don't think we want to pass a boolean parameter for this. This should be something derived - each line knows whether it has picklist items associated with it or not.

As I mentioned on the call, these methods don't really belong in the API, so let's move them to StockMovementController, or probably more appropriately, to PicklistController.

It seems reasonable, but are we sure this is equivalent?

As I mentioned on the call, let's not try to do anything new here. It was a good attempt, but I would like to make sure that new things are linked to a design and design review process, which will be handled as part of the discovery tickets and design sprints that Evan and I have mentioned in the past few weeks. If there's room to do a discovery and implementation in the same sprint, then great. But I suspect we're going to want to do these as separate activities across multiple sprints.

So for now, let's follow the current convention and add a generateExcel() method to dataService and we can work on OBIG-4 separately.

https://pihemr.atlassian.net/browse/OBIG-4

For this implementation, we should try to keep the previous code as-is (maybe move the main data retrieveal to a service) and just add in a way to switch on the rendering format.

This pseudocode - write this however you see fit (conditional, switch, etc) I just wanted to explain what I was thinking. I left out the code for the empty template case, so I'll let you figure out whether that should be included.

// Retrieve (and myabe validate) the stock movement for the given ID i.e. whether there is a stock movement with that id
def stockMovement = stockMovementService.getStockMovement(params.id)

// Keep the data building block from the previous version, but move to a service method.
def lineItems = picklistOrStockMovementService.getMeSomeData(stockMovement.picklist.id)

// FIXME We should eventually also handle content negotiation via file extension, request headers 
// and request parameters
if (!params.format || params.format == "csv") { 
    String csv = dataService.generateCsv(lineItems)
    response.setHeader("Content-disposition", "attachment; filename=\"StockMovementItems-${params.id}.csv\"")
    render(contentType: "text/csv", text: data.toString(), encoding: "UTF-8")
    return
} 
else if (params.format == "xls") {
    Workbook workbook = dataService.generateExcel(lineItems) 
    response.contentType = "application/vnd.ms-excel"
    response.setHeader("Content-disposition", "attachment; filename=\"StockMovementItems-${params.id}.xls\"")
    workbook.write(response.outputStream)
    response.outputStream.flush()
}
else { 
    throw new IllegalFormatException("Unable to determine the proper rendering format for request for format ${params.format}")
}

PICKLIST should be one word.

This switch here and in the next action looks like could be moved to one method, or sth.

I think we can repeat ourselves at the moment until we have a design pattern to deal with exporters and importers

Looking into Justin's comments, I thought it was meant to be moved and designed in OBIG, and here we wanted to use methods from the dataService. Let me know if I missed some discussion around it.