[OFBiz] Users - Requirement linking stuff

[Ashish Hareet]

Si,

I'm gonna take a shot at how a few things could be refactored. Keep in mind
that I've been playing with the requirements for only about 5 days, so please
excuse my ignorance if any...

I think we should leave the Requirement.requirementTypeId as is, cause the requirement
generation code based off QOH & ATP values of products is tightly integrated with the
requirement type "PRODUCT_REQUIREMENT"

What we could do is have another table called RequirementReason or add a field to
the Requirement entity called reasonId. I'd prefer the table just so that we don't complicate
it for other parts of OfBiz that use requirements.

Just to take it a little further, the OrderRequirementCommitment entity would just record
requirements that will help it fullfill itself. Any further requirements based on stock levels
should be recorded in another entity. If done this way, we have an order linked to only
one requirement, etc, etc. I think the requirements need to span out further, maybe Jacopo
can provide some feedback.

Meanwhile anybody got suggestions on how could I tell why a requirement was generated
based on the current framework...

Ashish Hareet
http://www.cpbinc.com


-----Original Message-----
Ashish -

How would you define the default facility?  Through the product store?

How about using Requirement.requirementTypeId and just adding a few more
types?  Maybe we should see what Jacopo thinks of it.

Si
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Jacopo Cappellato]

Ashish, Si,

this is a very interesting thread, thanks.

It is probably true that the existing implementation of requirements is
not fully complete, so it would be nice to put some effort to fill the gaps.

However I need to study&review the existing code and data model before this.
In the meantime a few notes (starting points for discussion):

* the facilityId field in the Requirement entity could be used to keep
track of the facility for which the requirement was created
* I agree that only auto requirements should be linked back to sales
orders (thru the OrderRequirementCommitment entity); stock requirements
should not
* it would be nice to create a serice that, given a set of requirements,
will add to them information about the 'primary' supplier (from
ProductSupplier): we could store this information in the RequirementRole
entity
* how to keep track of the requirement generation reason? Both using the
requirementTypeId or adding a new field such as requirementPurposeId
(following the pattern recently added to the ProductPrice entity) are
probably good options...

Jacopo

Ashish Hareet wrote:

> Si,
>
> I'm gonna take a shot at how a few things could be refactored. Keep in mind
> that I've been playing with the requirements for only about 5 days, so please
> excuse my ignorance if any...
>
> I think we should leave the Requirement.requirementTypeId as is, cause the requirement
> generation code based off QOH & ATP values of products is tightly integrated with the
> requirement type "PRODUCT_REQUIREMENT"
>
> What we could do is have another table called RequirementReason or add a field to
> the Requirement entity called reasonId. I'd prefer the table just so that we don't complicate
> it for other parts of OfBiz that use requirements.
>
> Just to take it a little further, the OrderRequirementCommitment entity would just record
> requirements that will help it fullfill itself. Any further requirements based on stock levels
> should be recorded in another entity. If done this way, we have an order linked to only
> one requirement, etc, etc. I think the requirements need to span out further, maybe Jacopo
> can provide some feedback.
>
> Meanwhile anybody got suggestions on how could I tell why a requirement was generated
> based on the current framework...
>
> Ashish Hareet
> http://www.cpbinc.com
>
>
> -----Original Message-----
> Ashish -
>
> How would you define the default facility?  Through the product store?
>
> How about using Requirement.requirementTypeId and just adding a few more
> types?  Maybe we should see what Jacopo thinks of it.
>
> Si
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users