FM8.5
Could someone advise me on how to set up a Purchase Order. Should I
use a line portal showing Produc description records or some other
approach.

Thanks

FM8.5
Could someone advise me on how to set up a Purchase Order. Should I
use a line portal showing Produc description records or some other
approach.

Thanks

In article
68d2e98d-ce6a-4034-b7da-f3d460e8c398 at (no spam) i4g2000prm.googlegroups.com>,
Smurf <wearesmurfs at (no spam) yahoo.ca> wrote:

FM8.5
Could someone advise me on how to set up a Purchase Order. Should I
use a line portal showing Produc description records or some other
approach.

Thanks

Seems to me FileMaker has some examples of this.

The general idea is a table for the products, a table for the Purchase
Orders, and a join table called LineItem

Each table has a primary key, customarily filled by unique serial number:
Product::__kpProductID
Order::__kpOrderID
LineItem::__kpLineItemID

LineItem also has 2 foreign key fields:
LineItem::_kfProductID
LineItem::_kfOrderID

Relationships:

PurchaseOrder::__kpOrderID = LineItem::_kfOrderID

Product::__kpProductID = LineItem::_kfProductID

Records in the LineItem table are created when you fill out an order.
You can do this by way of the relationship, or by scripting, and use of
drop-down menus.

Product should have fields for Price and QuantityOnHand.

LineItem should have fields for Quantity and ExtendedPrice, where
ExtendedPrice is calculated as the product of
Product::Price * LineItem::Quantity

Order would need a field for PriceSubtotal, calculated as:
Order::PriceSubtotal = Sum(LineItem::ExtendedPrice)

Bill wrote:
In article
68d2e98d-ce6a-4034-b7da-f3d460e8c398 at (no spam) i4g2000prm.googlegroups.com>,
Smurf <wearesmurfs at (no spam) yahoo.ca> wrote:

FM8.5
Could someone advise me on how to set up a Purchase Order. Should I
use a line portal showing Produc description records or some other
approach.

Thanks

Seems to me FileMaker has some examples of this.

The general idea is a table for the products, a table for the Purchase
Orders, and a join table called LineItem

Each table has a primary key, customarily filled by unique serial number:
Product::__kpProductID
Order::__kpOrderID
LineItem::__kpLineItemID

LineItem also has 2 foreign key fields:
LineItem::_kfProductID
LineItem::_kfOrderID

Relationships:

PurchaseOrder::__kpOrderID = LineItem::_kfOrderID

Product::__kpProductID = LineItem::_kfProductID

Records in the LineItem table are created when you fill out an order.
You can do this by way of the relationship, or by scripting, and use of
drop-down menus.

Product should have fields for Price and QuantityOnHand.

LineItem should have fields for Quantity and ExtendedPrice, where
ExtendedPrice is calculated as the product of
Product::Price * LineItem::Quantity

lineItems should also have a field price. If the Product::Price is used,
then historical integrity is lost (assuming using calculations)
Q: What happens when the ProductPrice changes?
A: the calculated line item extended price changes, and the OrderTotal
based on the lineItem::extendedCost also changes


SO perhaps the real question is, does this provide historical integrity,
if the calcs are auto-enter calcs, and if so is triggering an issue (as
it can be with related data), and not replace existing value is checked
(in order to maintain historical integrity) would be mandatory, what
happens when the user enters the wrong 1quantity, and then corrects the
quantity: the extended cost does not re-calculate.

I have always hard coded the lineitem cost, as a habit. What am I
missing using the related cost?



Order would need a field for PriceSubtotal, calculated as:
Order::PriceSubtotal = Sum(LineItem::ExtendedPrice)