Customer Specific Prices

[omelhus]

Hey,

Figured this would be a good place to discuss customer specific prices in the API.

It would be wonderful to have a field on product taking customerNo and quantity as parameters, and return customer specific prices.

 

[Marius Bancila]

The VBNXT GraphQL API has two characteristics:

• generic, al similar operations are handled uniformly
• data-oriented

What I mean by this is that the API is built by parsing the VBNXT data model. Anything that is added to the model is immediately exposed in GraphQL when the service is restarted. This data model contains tables, columns, access rights, processings, reports, etc. The API exposes, for instance, all the tables in the same manner (columns, filters, sorting order, etc). You can do the reads, inserts, updates, deletes similarly to all tables. Processing and exports are also associated with tables. So if you need to work with orders, you know that:

• the order field is where you read
• the order_create field is where you insert
• the order_update field is where you update
• the order_delete field is where you delete
• the order_aggregates field is where you can compute aggregate values
• the order_processings field is where you execute processings
• the order_reports field is where you execute reports

And if you know how to do this with orders you also know how to do with vouchers, batches, associates, gl accounts, and anything else.

We want to keep this generic aspect of the API. Therefore, we will not add function-like fields like the one you suggested to one or another table. That breaks both the generic aspect and the way we built the API. 

However, what you are asking for, is suitable for a processing, as far as I understand (on the product table). I imagine something like the following:

query GetProducts($cid : Int!, $customerNo : Int)
{
  useCompany(no: $cid)
  {
    product_processings
    {
      customer_price(args: {customerNo: $customerNo, quantity : 1})
      {
        items
        {
           productNo
           description
           price
           gorssPrice
           customerPrice
           customerGrossPrice
           discount1
           discount2
           discount3
        }
      }
    }
  }
}

[omelhus]

I get the sentiment, but I don't see the issue with creating an "extensions" field on a table in order to achieve this. I would not consider this a processing, but additional computed information. The reason I want this on the product table is that I want to fetch the product information with the prices alongside it in one request.

But your suggested approach might work if customer_price can take a filter of type FilterExpression_Product, and adhere to the same pagination cursor as Product. I can then send the same filter expression to both queries and stitch them afterwards.

[Marius Bancila]

Yes, processings use the same filter types that are used for reading or for mutations (updates, deletes). So, for a processing on the product table, the filter type is FilterExpression_Product.

[omelhus]

Hey!

Just want to make sure this issue is not forgotten. Any updates on where this is in the pipeline?

Cheers!

[omelhus]

And this is to let you know that I've managed to solve this one, and as far as I'm concerned you can close this idea.