I am playing with requisition list code in the B2BDirect store and
though some of you out there might have been down this road.

It appears that to share a requisition list (ORDERS.STATUS = Z) the
organization (ORDERS.ORGENTITY_ID) must be a parent organization.  This
seems to imply that you cannot create a buyer organization under the
Root Organization and use that buyer organization as the ORGENTITY_ID
for the orders you want to share within that entity.  Do you really need
to create a buyer organization "container" before creating the single
customer organization child?  The v5.5 Redbook SG246969 touches on this
a little but doesn't delve into great detail on why they created the
"container" organization before loading the ITSO buyer organization.

The table MBRREL seems to enforce the organization hierarchy as checked
by the ACRELGRP.CONDITIONS logic.  The MBRREL.SEQUENCE column is not
part of the unique index but the sequence does seem to make a big
difference when evaluating the parent-child relationships.  Anyone know
of caveats to having two organizations with the same sequence number?
Should the sequence in MBRREL.SEQUENCE match the order of a user's or
organization's DN column?  [I found useful comments in the
WC55SecurityGuide as not all was rolled into the WC v5.6 IC.]

Shared requisition list functionality is not coded at all in
RequisitionListDisplay.jsp which I thought odd since some of the
scriptlet code attempted to grab the shared list data and the property
files have numerous labels for shared lists.  Anyone using or had to
write their own requisition list code to support shared lists?  I
haven't spent too much time examining CustomB2BDirect, CWSAPToolTech,
PIRefApp, or any of the other 30 odd stores available.  Thought someone
here could save me time and point me to a SAR they had worked with before.

Any other thoughts on supporting shared requisition lists are
appreciated.  Best practices and all that.  Thanks for any replies.

R

[ Post a follow-up to this message ]

Just as FYI...I am currently evaluating the AdvancedB2BDirect store
which appears to have more private/shared list support than the
B2BDirect store.  Although this is a BE store, most of this code should
port to the non-BE versions I assume.

R

> I am playing with requisition list code in the B2BDirect store and
> though some of you out there might have been down this road.
>
> It appears that to share a requisition list (ORDERS.STATUS = Z) the
> organization (ORDERS.ORGENTITY_ID) must be a parent organization.  This
> seems to imply that you cannot create a buyer organization under the
> Root Organization and use that buyer organization as the ORGENTITY_ID
> for the orders you want to share within that entity.  Do you really need
> to create a buyer organization "container" before creating the single
> customer organization child?  The v5.5 Redbook SG246969 touches on this
> a little but doesn't delve into great detail on why they created the
> "container" organization before loading the ITSO buyer organization.
>
> The table MBRREL seems to enforce the organization hierarchy as checked
> by the ACRELGRP.CONDITIONS logic.  The MBRREL.SEQUENCE column is not
> part of the unique index but the sequence does seem to make a big
> difference when evaluating the parent-child relationships.  Anyone know
> of caveats to having two organizations with the same sequence number?
> Should the sequence in MBRREL.SEQUENCE match the order of a user's or
> organization's DN column?  [I found useful comments in the
> WC55SecurityGuide as not all was rolled into the WC v5.6 IC.]
>
> Shared requisition list functionality is not coded at all in
> RequisitionListDisplay.jsp which I thought odd since some of the
> scriptlet code attempted to grab the shared list data and the property
> files have numerous labels for shared lists.  Anyone using or had to
> write their own requisition list code to support shared lists?  I
> haven't spent too much time examining CustomB2BDirect, CWSAPToolTech,
> PIRefApp, or any of the other 30 odd stores available.  Thought someone
> here could save me time and point me to a SAR they had worked with before.
>
> Any other thoughts on supporting shared requisition lists are
> appreciated.  Best practices and all that.  Thanks for any replies.
>
>                 R

[ Post a follow-up to this message ]