Orderables update?

Hello everyone,

  Some time ago I've noticed that the Orderables controller does not allow updating once created orderables. When I asked about it, the answer was that the Orderable instances are meant to be immutable by design. This means that currently there's no way to do anything with the orderable that has already been created (delete is not supported either and archiving is still just in plans).

  I wanted to ask what are the core team plans with the Orderable resources. Per Malawi requirements, we are supposed to update prices at the end of every reporting cycle (monthly) and the only way to do so is by manually updating the database, which of course is time-consuming and error-prone. I've also heard that the program_orderables association may change and require and update. Are we planning to have the archiving option in orderables soon? (which release?) Should an update endpoint be considered until we have a proper archiving pattern established? I'd by all means want to avoid having to alter the orderables manually in the database every few days, so I'm curious if you have any other suggestions on how to manage orderables.

Best regards,

  Sebastian.
···


Sebastian Brudziński

    Software Developer / Team Leader

sbrudzinski@soldevelo.com

SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

We want to have Orderables immutable, but this shouldn’t be the case for ProgramOrderables. It’s reasonable to assume that prices will be changing or orderables will be assigned to or out of programs. I do not think the intention is to have that relationship immutable.

Currently the program orderable is tied to the orderable resource - I believe there should be a separate resource for this program-orderable relationship, i.e orderables/{id}/programs - this would allow updates to the program orderable.

I understand this is a chore for Malawi - you have to update about 20 prices in PostgreSQL admin app or whatever you use. Probably something we should consider doing after release.

Regards,

Paweł

P.S. I’ve been asked to bump this


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Wed, Aug 16, 2017 at 12:24 PM, Sebastian Brudziński sbrudzinski@soldevelo.com wrote:

Hello everyone,

  Some time ago I've noticed that the Orderables controller does not allow updating once created orderables. When I asked about it, the answer was that the Orderable instances are meant to be immutable by design. This means that currently there's no way to do anything with the orderable that has already been created (delete is not supported either and archiving is still just in plans).
  I wanted to ask what are the core team plans with the Orderable resources. Per Malawi requirements, we are supposed to update prices at the end of every reporting cycle (monthly) and the only way to do so is by manually updating the database, which of course is time-consuming and error-prone. I've also heard that the program_orderables association may change and require and update. Are we planning to have the archiving option in orderables soon? (which release?) Should an update endpoint be considered until we have a proper archiving pattern established? I'd by all means want to avoid having to alter the orderables manually in the database every few days, so I'm curious if you have any other suggestions on how to manage orderables.

Best regards,

  Sebastian.


Sebastian Brudziński

    Software Developer / Team Leader


     sbrudzinski@soldevelo.com


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/7bd13f59-f2f5-844a-0329-3babbed090a6%40soldevelo.com.

For more options, visit https://groups.google.com/d/optout.

Paweł Gesek

    Technical Project Manager

     pgesek@soldevelo.com / +48 690 020 875

Thanks Sebastian (and Pawel for the bump),

The intention was never to make the relationship between Orderable and Program (aka ProgramOrderable) immutable. We’re going to have a conversation here soon on how to build this in a way that:

  • doesn’t break other services (Requisition for example)
  • supports multiple pricing approaches (e.g. by program, by facility schedule)
  • helps implementations adopt GS1 (forming Orderable by way of TradeItems and CommodityTypes) concepts

Given that 3.2 releases in just over a week, I wouldn’t expect significant changes to drop in 3.2, though we are working toward it. That prices are being updated every month for every Orderable is new to me though. Previously I’ve been told that updating a price is a yearly process for most Programs. Assuming we solve the archiving issue, how would Malawi want to update all of the Orderable prices each month? By a CSV upload with thousands of new prices in a batch? By individually admin screens, where you update the prices one-by-one? In GS1 this could be sourced automatically from a GDSN which could make any Malawi administration much less work, though I haven’t heard that Malawi is preparing to connect to a GDSN yet…

Let us know more about the use-case that’d work best, including the longer term Malawi support ideal, and we can work together to get the right feature set.

Best,

Josh

···

On Wednesday, August 16, 2017 at 3:24:10 AM UTC-7, Sebastian Brudziński wrote:

Hello everyone,

  Some time ago I've noticed that the Orderables controller does not allow updating once created orderables. When I asked about it, the answer was that the Orderable instances are meant to be immutable by design. This means that currently there's no way to do anything with the orderable that has already been created (delete is not supported either and archiving is still just in plans).
  I wanted to ask what are the core team plans with the Orderable resources. Per Malawi requirements, we are supposed to update prices at the end of every reporting cycle (monthly) and the only way to do so is by manually updating the database, which of course is time-consuming and error-prone. I've also heard that the program_orderables association may change and require and update. Are we planning to have the archiving option in orderables soon? (which release?) Should an update endpoint be considered until we have a proper archiving pattern established? I'd by all means want to avoid having to alter the orderables manually in the database every few days, so I'm curious if you have any other suggestions on how to manage orderables.

Best regards,

  Sebastian.


Sebastian Brudziński

    Software Developer / Team Leader


     sbrudzinski@soldevelo.com


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Hi Josh,

  thanks for the answer and clarifications. The prices that we are using are taken from the CMST catalogue and I've been told that they can change every reporting period (so monthly). I can imagine an automated approach to have the updates on new products and prices. This would of course require coordination with the CMST (if I recall the meeting with them correctly, their online, public one wasn't always up-to-date). Anyways, based on the frequency and number of updates, I believe Malawi will want to automate this eventually. For now, the plan is to use CSV upload where possible. I'm also not sure how stakeholders would feel on updates via administrative screens given the amount of updates they have to make - I can probably gather and share preferences early next week.

  Having ProgramOrderables updateable will be great, but I heard that Malawi team is also interested in updating some of the properties that live directly in an Orderable, like pack size. This is because the pack sizes that we currently have do not always correspond to the ones supplied by CMST. Although it didn't happen yet, I can also imagine the Malawi team want to update any typos in product names, shall there be any (and probably be able to do so without archiving and re-creating the orderable). Due to the above and the fact that we need to make a lot of updates to products in the next days, we will be most likely looking into a simple SQL-based solution for Orderable updates for now.

Best regards,

  Sebastian.
···

On 22.08.2017 06:43, Josh Zamor wrote:

Thanks Sebastian (and Pawel for the bump),

    The intention was never to make the relationship between Orderable and Program (aka ProgramOrderable) immutable.  We're going to have a conversation here soon on how to build this in a way that:
  • doesn’t break other services (Requisition for example)
  •         supports multiple pricing approaches (e.g. by program, by facility schedule)
    
  •         helps implementations adopt GS1 (forming Orderable by way of TradeItems and CommodityTypes) concepts
    
      Given that 3.2 releases in just over a week, I wouldn't expect significant changes to drop in 3.2, though we are working toward it.  That prices are being updated every month for every Orderable is new to me though.  Previously I've been told that updating a price is a yearly process for most Programs.  Assuming we solve the archiving issue, how would Malawi want to update all of the Orderable prices each month?  By a CSV upload with thousands of new prices in a batch?  By individually admin screens, where you update the prices one-by-one?  In GS1 this could be sourced automatically from a GDSN which could make any Malawi administration much less work, though I haven't heard that Malawi is preparing to connect to a GDSN yet...
      Let us know more about the use-case that'd work best, including the longer term Malawi support ideal, and we can work together to get the right feature set.

Best,

Josh

    On Wednesday, August 16, 2017 at 3:24:10 AM UTC-7, Sebastian Brudziński wrote:

Hello everyone,

          Some time ago I've noticed that the Orderables controller does not allow updating once created orderables. When I asked about it, the answer was that the Orderable instances are meant to be immutable by design. This means that currently there's no way to do anything with the orderable that has already been created (delete is not supported either and archiving is still just in plans).
          I wanted to ask what are the core team plans with the Orderable resources. Per Malawi requirements, we are supposed to update prices at the end of every reporting cycle (monthly) and the only way to do so is by manually updating the database, which of course is time-consuming and error-prone. I've also heard that the program_orderables association may change and require and update. Are we planning to have the archiving option in orderables soon? (which release?) Should an update endpoint be considered until we have a proper archiving pattern established? I'd by all means want to avoid having to alter the orderables manually in the database every few days, so I'm curious if you have any other suggestions on how to manage orderables.

Best regards,

          Sebastian.


Sebastian Brudziński

                              Software Developer / Team Leader

             sbrudzinski@soldevelo.com
      **![](https://lh3.googleusercontent.com/proxy/Kq7icsK3MEQjYLwBW84HwuYjQ8aFuyyirMOzt_ENZ5BgyyRVaFVgsbO-vnqZPEKtkcm1Gs2mKJSDSi59adej7wSt1KiO3u5QJa2SfrMvGRh8cyONHJScEXiljA=w5000-h5000)

          SolDevelo** Sp. z o.o. [LLC] / [www.soldevelo.com](http://www.soldevelo.com)

        Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland

        Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

  You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

  To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

  To post to this group, send email to openlmis-dev@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/84e413a8-972b-491b-9c90-7351020deb7a%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/84e413a8-972b-491b-9c90-7351020deb7a%40googlegroups.com?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Sebastian Brudziński

    Software Developer / Team Leader


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
sbrudzinski@soldevelo.com