Purchase orders

#1

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

#2

On Oct 12, 4:20*pm, Smurf <wearesmu... (AT) yahoo (DOT) ca> wrote:

Quote:

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

You should use a portal showing records from a PO-Product Join table.

G

#3

Bill wrote:

Quote:

In article
68d2e98d-ce6a-4034-b7da-f3d460e8c398...oglegroups.com>,
Smurf <wearesmurfs (AT) yahoo (DOT) 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?

Quote:

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

#4

In article <hb2u0a$d8f$1 (AT) aioe (DOT) org>, cortical <cb (AT) corticaldat (DOT) com.au>
wrote:

Quote:

Bill wrote:
In article
68d2e98d-ce6a-4034-b7da-f3d460e8c398...oglegroups.com>,
Smurf <wearesmurfs (AT) yahoo (DOT) 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)

I agree that you should have a field for line item price, filled by
lookup or calculation from Product price. That keeps historical
integrity. Sorry to have overlooked that in my earlier response.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Purchase orders

comp.databases.filemaker comp.databases.filemaker

Purchase orders - 10-12-2009 , 05:20 PM

Re: Purchase orders - 10-12-2009 , 08:40 PM

Re: Purchase orders - 10-13-2009 , 05:12 PM

Re: Purchase orders - 10-13-2009 , 08:01 PM