1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Ticket #19 (accepted task)

Opened 4 years ago

Last modified 2 years ago

Purchase Orders

Reported by: mchavezg Owned by: mchavezg
Priority: major Milestone: Expanding beyond the basics
Component: Squeeze -admin interface- Version: git persa branch
Keywords: Cc:

Description (last modified by mchavezg) (diff)

Purchase Orders on squeeze.
Manual or automatic based on products availability, providers and sell history for them.

Adding a field to check the products received in the purchase order. Or a table for received_Items (related to p.o.)

Change History

  Changed 4 years ago by mchavezg

  • status changed from new to accepted

  Changed 4 years ago by mchavezg

  • description modified (diff)

follow-up: ↓ 4   Changed 2 years ago by free2malloc

Alright, it's been a year and a half.. :)

I have a half-implemented Purchase Orders system which adds a page to SqueezeView?, introduces two tables (purchaseorders and purchaseorders_entries), adds a .cpp and corresponding .h, and a multiuse dialog (as a .ui) for creating, generating, editing, receiving, or viewing a purchase order. (The view is swapped within a QStackedWidget depending on the function of the dialog.)

Products table has "reorderpoint" and "reorderpar" added, and the ProductEditor? dialog in Squeeze has these added respectively. They also appear on the Table-view of the Products page.

A product's Reorder Point defines at which point that product will be reordered on an automatically generated purchase order. For example, if a reorder point of "Able Brand Cheese" is set to 5 and current stock is 10, it will not appear on a generated invoice*.

The Reorder Par defines what our desired product stock will be. Generated invoices will order enough of a product to bring stock of it to this quantity. So if, for example, the reorder point of "Able Brand Cheese" is set to 5 and current stock is 2, if the "Reorder Par" is set to 20 a generated PO will order 18.

I've had two thoughts so far on this system:

1) smart reordering based on sales trends would be nice, and reorder par could be instead used as a "minimum on-hand" quantity OR an estimated "time until depleted" (eg: 2 weeks worth of stock.)

2) cases ordered may only ship in certain multiples, such as 12 to a case. i plan on adding a "caseqty" field to the database and updating the Squeeze code appropriately.

Does this sound good? Do you have some code done for this already?

in reply to: ↑ 3 ; follow-up: ↓ 5   Changed 2 years ago by mchavezg

Replying to free2malloc:

Alright, it's been a year and a half.. :)

I have a half-implemented Purchase Orders system which adds a page to SqueezeView?, introduces two tables (purchaseorders and purchaseorders_entries), adds a .cpp and corresponding .h, and a multiuse dialog (as a .ui) for creating, generating, editing, receiving, or viewing a purchase order. (The view is swapped within a QStackedWidget depending on the function of the dialog.)

Products table has "reorderpoint" and "reorderpar" added, and the ProductEditor? dialog in Squeeze has these added respectively. They also appear on the Table-view of the Products page.

A product's Reorder Point defines at which point that product will be reordered on an automatically generated purchase order. For example, if a reorder point of "Able Brand Cheese" is set to 5 and current stock is 10, it will not appear on a generated invoice*.

The Reorder Par defines what our desired product stock will be. Generated invoices will order enough of a product to bring stock of it to this quantity. So if, for example, the reorder point of "Able Brand Cheese" is set to 5 and current stock is 2, if the "Reorder Par" is set to 20 a generated PO will order 18.

I've had two thoughts so far on this system:

1) smart reordering based on sales trends would be nice, and reorder par could be instead used as a "minimum on-hand" quantity OR an estimated "time until depleted" (eg: 2 weeks worth of stock.)

2) cases ordered may only ship in certain multiples, such as 12 to a case. i plan on adding a "caseqty" field to the database and updating the Squeeze code appropriately.

Does this sound good? Do you have some code done for this already?

Sounds great! Still no code about this feature. Go ahead.

Just one thing to think a little more. The purchase order will be just an order without payment or paid in the moment of emitting the purchase order. When the payment is done, remember to make a transaction (type: purchase) to keep (accounting) records about the purchase..
You can see the code in the purchase feature in squeeze (squeezeview.cpp line 1962 on the doPurchase() method and code from purchaseeditor.cpp could help).

in reply to: ↑ 4   Changed 2 years ago by free2malloc

Replying to mchavezg:

Just one thing to think a little more. The purchase order will be just an order without payment or paid in the moment of emitting the purchase order. When the payment is done, remember to make a transaction (type: purchase) to keep (accounting) records about the purchase..
You can see the code in the purchase feature in squeeze (squeezeview.cpp line 1962 on the doPurchase() method and code from purchaseeditor.cpp could help).

Absolutely, the function for this is simply "Receive" to receive against a purchase order.

Note: See TracTickets for help on using tickets.