A "service" is really a type of Product in OFBiz. I guess for the
most part when you have a service product you would just receive it
as an expensed item, or that would generally be the OrderItemType.
Whether the purchase of a service product result in creation of a
WorkEffort is a separate issue, and would happen for a service type
product regardless of the OrderItemType. I should qualify that would
be for sales orders. For purchase orders there would be some way of
receiving it, but the point is that when it's received the
OrderItemType would determine what should be done with it, and for
services the question for purchasing is more about how notification
of completion of services is done rather than how to account for them
or manage them after receipt, as is the case for goods.
-David
On Dec 8, 2006, at 11:35 AM, Si Chen wrote:
Yes, you're right fixed asset vs. inventory vs. supplies vs.
service. I think there should be separate options for each of
these right? Create fixed asset vs. receive inventory vs. create
work effort vs. expense supplies directly?
On Dec 8, 2006, at 10:19 AM, David E Jones wrote:
Do you mean Fixed Asset versus Inventory versus Supplies versus
Service? I still don't see what fixed asset, product, and service
have to do with each other...
-David
On Dec 8, 2006, at 10:45 AM, Si Chen wrote:
Ok, I agree with what you're saying. I guess it doesn't matter
as much what happens when the order is created, but so long as
after the order is created, a different step is possible for
fixed asset vs. product vs. service.
On Dec 7, 2006, at 11:14 AM, David E Jones wrote:
On Dec 7, 2006, at 11:33 AM, Si Chen wrote:
David,
So what do you think would be the best approach for creating a
fixed asset after a PO is approved? Should there be a link to
receive the fixed asset, as opposed to receive inventory, which
causes the fixed asset to be created?
This is usually known when an order is created, hence the
different OrderItemTypes to denote this. When an order is
received (or the shipment for an order, rather) we can look at
those and see what the product purchase was intended for, ie
inventory, supplies (expensed), or fixed asset.
We could create a UI that allows manually overriding that when
the order is received, but even that would start with the
original intention denoted by the orderItemTypeId.
-David
On Dec 3, 2006, at 12:56 AM, David E Jones wrote:
David,
I just read David's post http://lists.ofbiz.org/pipermail/dev/
2006-May/011004.html and your posting and I think I would
suggest something a little different. The different
OrderItemTypes for product vs fixed asset vs service is a good
idea, but it should not be presented to the user. Rather, it
should be possible to set up a Product as a "Fixed Asset",
"Finished Good", and "Service", and the storeOrder service
should figure out correct OrderItemType for it. During order
creation (shopping cart) any order item is like any other
order item, but then when the order is created the different
types are stored.
Why the groups "Fixed Asset", "Finished Good", and "Service"?
What would those mean? I guess I'm confused because it seems
like an arbitrary selection of ProductTypes and other general
stuff. A FixedAsset is (or can be) an instance of a Product,
which can have a type of "Finished Good", for example.
Then, when the order is created, depending on the different
types of order items, you can 1) receive inventory or ship
inventory (physical products) 2) automatically fulfill for
digital products--already implemented, you can start your own
iTunes with ofbiz 3) commission a fixed asset item if it's a
fixed asset order item and 4) create a workeffort if it's a
service item
Here again this is kind of a funny mix of things, and I'm not
sure what sort of process you have in mind. There are generally
different processes for different things, and these can of
course vary by the company. Purchases and sales are obviously
different too. For service sales you could trigger creation of
a WorkEffort, but for many companies that plan and quote before
they sell the WorkEffort would already exist, for example.
-David
Best Regards,
Si
[EMAIL PROTECTED]
Best Regards,
Si
[EMAIL PROTECTED]
Best Regards,
Si
[EMAIL PROTECTED]
