Long Term Purchase Agreements

Feature
1

Rational

In order to get better purchase conditions, some companies define long term purchase agreements with their suppliers. This agreement involves the comitement to buy a minimal quantity of products over a period of time.

Once an agreement is reached, individual purchases are issued to request the supply of the products.

Proposal

A new purchase Agreement model will be added to track the following information:

  • Number:
  • Supplier: The supplier on which the agreement is done
  • Reference:
  • Start Date
  • End Date: The agreement end date (can be empty if not know in advance)
  • Agreed quantity:
  • Product: (optional)
  • Supply: (date)
  • Product Supplier Lines: A list of ProductSupplier lines that will apply to this Agreement

The system will be able to compute the following information:

  • Requested Quantity Quantity on processing purchases still not received
  • Received Quantity: The quantity already on our warehouses

The purchase date will be used to determine if there is any active agreement for the current purchase. If so, this value will be used for Matching criteria on ProductSupplier Prices, so agreement conditions (special price, special delivery time) will be automatically computed on the purchase.

Implementation

2

What if it is not based on a single product but a group of products?

Why do you need such link. All purchases to the supplier should fall under the agreement.

What is the goal of such workflow? Why putting in the system something which is negotiating, it does not add any value?

Which conditions?

3

The idea is to define all the products on the Agreement, thats why I added a list of.

You are right. But only the purchases which date is between the agreeement date.

The conditions may be a Special Price or a Special delivery time. As this information is currently stored on ProductSupplier the idea is to a new matching criteria on the Product Supplier to determine that this lines will only apply if the agreement is active.

Indeed we can determine which agreement to match by matching the purchase date with the agreement date.

Acknowledged. So I removed the workflow from the proposal

4

I mean the agreement could be something like: you commit to purchase for 100unit of bicycles not matter the model.

I guess it should be checked but you probably could add a start/end date on product supplier.

Then why not using the product supplier directly by adding the required match criteria on the prices.

5

Yes, this is possible on the agreement. Also it’s possible to specify a generic product and then purchase specific products. Let me put an example:

We agree to buy 100units of bicycles. With the following prices:

  • For road bikes the price will be 1000€ per unit
  • For MTB bikes the price will be 500€ per unit.
    …
  • For Areo Road Bikes the price will be 1500€ per unit.

I think it will be better to not include a list of agreed quantities, but create an agreement for each “Group of products” or product. On the agreement we specify the quantity agreed and optionally the product and the supply date.

I will update the proposal acordingly

6

And what will be the improvement compared to the product supplier (with extra criteria)?
For me, it is just a complex model which brings nothing for the workflow except complexity.

7

Indeed the product supplier is not the more relevant part.

The main need is to know for each agreement the delivered and the pending quantity.

8

So I think it should solve differently. We could have a report on purchase and a generic feature to store target on the report (depending of the context). This way the user can compare the target with the real value and take action.
I find it is a simpler solution but more powerful because it could be applied to any kind of reports (and even replace the budget blueprint).

9

This topic was automatically closed after 12 days. New replies are no longer allowed.