Re: RE: RE: RE: Quantity missing for inventory transfer records

[Pierre Smits]

An internal order policy with appropriate process definition and protocols
is a widely accepted solution.

Best regards

Pierre

On Sat, 28 Oct 2017 at 14:59 James Yong  wrote:

> +1 for Inventory Transfer without using Order entity.
>
> On 2017-10-28 02:13, Swapnil Shah  wrote:
> > Thanks all your suggestions.
> > I think similarity of the discussed requirements with ordering flow lead
> to
> > the suggestions to use Order model. I don't have strong preference to use
> > one over another as long as we are able to support bulk of the discussed
> > requirements in this thread in a less complicated, easy to maintain and
> most
> > flexible way.
> >
> > If we all are in agreement to take Inventory Transfer route then let's
> cut a
> > JIRA to proceed with it.
> >
> > Thanks,
> > Swapnil
> >
> > -Original Message-
> > From: James Yong [mailto:jamesy...@apache.org]
> > Sent: Wednesday, October 25, 2017 8:27 PM
> > To: dev@ofbiz.apache.org
> > Subject: Re: RE: RE: RE: Quantity missing for inventory transfer records
> >
> > Hi all,
> >
> > Having suggested possible entity changes to both approaches (with or
> without
> > Order entity), I prefer not to make use of Order entity for inventory
> > transfer. Order entity is currently shared by Sales Order and Purchase
> > Order. Using Order for transfer may make it harder to expand inventory
> > transfer functionalities in the future.
> >
> > We can also look at OpenTap's implementation for reference.
> > http://www.opentaps.org/docs/index.php/Transfer_Shipment
> >
> > Regards,
> > James Yong
> >
> > On 2017-10-25 11:43, Swapnil Shah 
> wrote:
> > > Let's keep in mind that in reality it's the same single shipment that
> > > needs to change hands between source and destination facility as a
> > > part of single operational system. If we are willing to take Order
> > > model route, then is it possible that we introduce a new order type
> > > 'Replenishment Order (RO)' or 'Transfer Order' along with new Shipment
> > > Type ‘Transfer Shipment’. And allow to have these ROs processed
> > > through this single transfer shipment.
> > > What it would mean is that:
> > >
> > >1. Create RO with Shipping Facility (i.e. originating
> > >DC/Warehouse/Store) and Receiving Facility (i.e. destination
> > >DC/Warehouse/Store). Possibly with same ‘Bill/Ship From Vendor’
> and
> > >‘Bill/Ship to Customer’ party id (as long as both originating
> and
> > >destination facilities are owned by same registered company or
> business
> > >entity).
> > >2. Allow to selectively reserve Inventory Items against RO items
> (even
> > >if it means overriding existing reservations).
> > >3. Allow warehouse/facility to group all common destination RO in a
> > >single ‘Transfer Shipment’ during picking.
> > >4. Once shipment is packed/shipped from originating facility then
> move
> > >its status to ‘Shipped’. At the same time linked RO’s status
> can
> > > also be
> > >marked as ‘Shipped’. This should affect the on Hand to the tune
> of
> > > shipped
> > >units.
> > >5. Generate only a separate Tax Invoice (if applicable) against
> linked
> > >RO.
> > >6. Allow Destination Facility to ‘Receive’ the ‘Shipped’ RO
> > > (similar to
> > >PO receiving) but under the very same linked Transfer Shipment that
> was
> > >shipped from originating facility. This should affect the On hand to
> > > the
> > >tune of received units.
> > >7. Once whole Shipment is successfully received, move the shipment
> to
> > >‘Received’ status. And at the same time linked RO can also be
> > > marked as
> > >‘Completed’.
> > >8. Hit the necessary and relevant GL accounts and posting in the
> > > process
> > >wherever needed.
> > >
> > >
> > >
> > > I am not sure about level of technical changes involved against other
> > > suggested approaches, so please feel free to ignore if it looks over
> > > complicated.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Swapnil
> > >
> > >
> > >
> > > -Original Message-
> > > From: Vaibhav Jain [mailto:vaibhav.j...@hotwaxsystems.com]
> > > Sent: Tuesday, October 24, 2017 6:46 PM
> > > To: dev@ofbiz.apache.org
> > > Subject: Re: RE: RE: Quantity missing for inventory transfer records
> > >
> > >
> > >
> > > Hello All,
> > >
> > >
> > >
> > > Thanks Swapnil for the detailed business scenarios.
> > >
> > >
> > >
> > > Thanks James for the reply.
> > >
> > >
> > >
> > > I just want to convey that there is no need to use a separate data
> > > model for inventory transfer. We can use order data model for inventory
> > > transfer.
> > >
> > >
> > >
> > > We can create a SO from one facility which create an automated PO for
> > > another facility. Inventory transfer will be done using sales/purchase
> > > order.
> > >
> > >
> > >
> > > Stock move is used for 

Re: RE: RE: RE: Quantity missing for inventory transfer records

[James Yong]

+1 for Inventory Transfer without using Order entity.

On 2017-10-28 02:13, Swapnil Shah  wrote: 
> Thanks all your suggestions.
> I think similarity of the discussed requirements with ordering flow lead to
> the suggestions to use Order model. I don't have strong preference to use
> one over another as long as we are able to support bulk of the discussed
> requirements in this thread in a less complicated, easy to maintain and most
> flexible way.
> 
> If we all are in agreement to take Inventory Transfer route then let's cut a
> JIRA to proceed with it.
> 
> Thanks,
> Swapnil
> 
> -Original Message-
> From: James Yong [mailto:jamesy...@apache.org]
> Sent: Wednesday, October 25, 2017 8:27 PM
> To: dev@ofbiz.apache.org
> Subject: Re: RE: RE: RE: Quantity missing for inventory transfer records
> 
> Hi all,
> 
> Having suggested possible entity changes to both approaches (with or without
> Order entity), I prefer not to make use of Order entity for inventory
> transfer. Order entity is currently shared by Sales Order and Purchase
> Order. Using Order for transfer may make it harder to expand inventory
> transfer functionalities in the future.
> 
> We can also look at OpenTap's implementation for reference.
> http://www.opentaps.org/docs/index.php/Transfer_Shipment
> 
> Regards,
> James Yong
> 
> On 2017-10-25 11:43, Swapnil Shah  wrote:
> > Let's keep in mind that in reality it's the same single shipment that
> > needs to change hands between source and destination facility as a
> > part of single operational system. If we are willing to take Order
> > model route, then is it possible that we introduce a new order type
> > 'Replenishment Order (RO)' or 'Transfer Order' along with new Shipment
> > Type ‘Transfer Shipment’. And allow to have these ROs processed
> > through this single transfer shipment.
> > What it would mean is that:
> >
> >1. Create RO with Shipping Facility (i.e. originating
> >DC/Warehouse/Store) and Receiving Facility (i.e. destination
> >DC/Warehouse/Store). Possibly with same ‘Bill/Ship From 
> > Vendor’ and
> >‘Bill/Ship to Customer’ party id (as long as both 
> > originating and
> >destination facilities are owned by same registered company or business
> >entity).
> >2. Allow to selectively reserve Inventory Items against RO items (even
> >if it means overriding existing reservations).
> >3. Allow warehouse/facility to group all common destination RO in a
> >single ‘Transfer Shipment’ during picking.
> >4. Once shipment is packed/shipped from originating facility then move
> >its status to ‘Shipped’. At the same time linked 
> > RO’s status can
> > also be
> >marked as ‘Shipped’. This should affect the on Hand to the 
> > tune of
> > shipped
> >units.
> >5. Generate only a separate Tax Invoice (if applicable) against linked
> >RO.
> >6. Allow Destination Facility to ‘Receive’ the 
> > ‘Shipped’ RO
> > (similar to
> >PO receiving) but under the very same linked Transfer Shipment that was
> >shipped from originating facility. This should affect the On hand to
> > the
> >tune of received units.
> >7. Once whole Shipment is successfully received, move the shipment to
> >‘Received’ status. And at the same time linked RO can also 
> > be
> > marked as
> >‘Completed’.
> >8. Hit the necessary and relevant GL accounts and posting in the
> > process
> >wherever needed.
> >
> >
> >
> > I am not sure about level of technical changes involved against other
> > suggested approaches, so please feel free to ignore if it looks over
> > complicated.
> >
> >
> >
> > Thanks,
> >
> > Swapnil
> >
> >
> >
> > -Original Message-
> > From: Vaibhav Jain [mailto:vaibhav.j...@hotwaxsystems.com]
> > Sent: Tuesday, October 24, 2017 6:46 PM
> > To: dev@ofbiz.apache.org
> > Subject: Re: RE: RE: Quantity missing for inventory transfer records
> >
> >
> >
> > Hello All,
> >
> >
> >
> > Thanks Swapnil for the detailed business scenarios.
> >
> >
> >
> > Thanks James for the reply.
> >
> >
> >
> > I just want to convey that there is no need to use a separate data
> > model for inventory transfer. We can use order data model for inventory
> > transfer.
> >
> >
> >
> > We can create a SO from one facility which create an automated PO for
> > another facility. Inventory transfer will be done using sales/purchase
> > order.
> >
> >
> >
> > Stock move is used for intra-warehouse inventory transfer while
> > inventory transfer is for inter-warehouse inventory transfer.
> >
> >
> >
> > We can achieve inventory transfer using order data model instead of
> > using separate data model for inventory transfer.
> >
> >
> >
> >1. On the basis of from party and to party we can identify that
> > order is
> >
> >

Re: All roleType entities should maintain lifespan

[Suraj Khurana]

Hi Scott,

Thanks for your response.
In figure-4 he

**re
,
it is specified that we do not need to manage partyRole entity as party
role is specific to something (like work effort) i.e. party does not have a
dependency on party role for the role in any entity.
IMO, we should have PartyRole entity so that it becomes easy to filter
parties in specific roles, but, on the other hand, we should not maintain
this FK relationship while adding records to other entities like OrderRole,
AdjustmentRole etc.

One use case could be like I mentioned earlier, it becomes easy to filter
parties in specific roles like suppliers, distributors etc.

--
Thanks and Regards
*Suraj Khurana* | Sr. Enterprise Software Engineer
*HotWax Commerce*  by  *HotWax Systems*
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010


On Fri, Sep 29, 2017 at 1:30 PM, Scott Gray 
 wrote:

> Hi Suraj,
>
> I still haven't seen an example of a useful use case for adding
> from/thruDate fields to the PartyRole table.  Did you have anything in mind
> that it might help with?
>
> I'd honestly prefer to remove it rather than expand it.
>
> Regards
> Scott
>
> On 29 September 2017 at 20:41, Suraj Khurana  ystems.com> wrote:
>
>> Hello,
>>
>> There has been already a discussion under OFBIZ-5959
>>  regarding this.
>> I would like to bring this point again into attention and would like to
>> suggest that we should introduce lifespan to all such entities.
>> Also, PartyRole FK constraint should be removed while adding a record of
>> that party in any other role entity, earlier it was also discussed that it
>> becomes cumbersome to manage that and there is not any specific need to
>> have that in real time as well.
>>
>> Let me know your thoughts on this.
>> --
>> Thanks and Regards
>> *Suraj Khurana* | Sr. Enterprise Software Engineer
>> *HotWax Commerce*  by  *HotWax Systems*
>> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>>
>
>
*Suraj Khurana* | Sr. Enterprise Software Engineer
HotWax Commerce   by  HotWax Systems

Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
Cell phone: +91 96697-50002




HotWax Systems  recently received 8
mentions in *The Gartner Digital Commerce Vendor Guide, 2016 *by Gartner,
Inc., the world's leading IT research and advisory company.

[image: Inline image 1]

On Fri, Sep 29, 2017 at 11:29 PM, Nicolas Malin 
wrote:

> Add lifespan to PartyRole seems to me just to complex perhaps impossible.
> If you want indicate (as example) that a party is a customer from / to with
> a lifespan on PartyRole they missing the information customer from who ?
>
> PartyRole is a technical entity as functional entity (it's border line :)
> ). Prefer to manage this role lifespan information with PartyRelationship
> and hidden PartyRole value to end user.
>
> A party with "bill to customer" role associate to an order would be for
> the system always a "bill to customer" and not only for the life order
> time. But in the other case, you can consider that this "bill to customer"
> is finish for your company and you can indicate this through
> PartyRelationship
>
> Nicolas
>
>
>
> Le 29/09/2017 à 10:00, Scott Gray a écrit :
>
>> Hi Suraj,
>>
>> I still haven't seen an example of a useful use case for adding
>> from/thruDate fields to the PartyRole table.  Did you have anything in
>> mind
>> that it might help with?
>>
>> I'd honestly prefer to remove it rather than expand it.
>>
>> Regards
>> Scott
>>
>> On 29 September 2017 at 20:41, Suraj Khurana <
>> suraj.khur...@hotwaxsystems.com> wrote:
>>
>> Hello,
>>>
>>> There has been already a discussion under OFBIZ-5959
>>>  regarding this.
>>> I would like to bring this point again into attention and would like to
>>> suggest that we should introduce lifespan to all such entities.
>>> Also, PartyRole FK constraint should be removed while adding a record of
>>> that party in any other role entity, earlier it was also discussed that
>>> it
>>> becomes cumbersome to manage that and there is not any specific need to
>>> have that in real time as well.
>>>
>>> Let me know your thoughts on this.
>>> --
>>> Thanks and Regards
>>> *Suraj Khurana* | Sr. Enterprise Software Engineer
>>> *HotWax Commerce*  by  *HotWax Systems*
>>> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>>>
>>>
>

Re: Move buildbot messages out of DEV mailing lists

[Jacques Le Roux]

Hi,

As I thought, it was not an issue in our script but effectively an infra issue

So we still have repetitive success, or failure, reports, when it should be 
only triggered on state changes .

I have created INFRA-15394 for that

Jacques


Le 24/10/2017 à 13:21, Jacques Le Roux a écrit :

I tried a small fix, let's see

If it does not work, the best is to fill at request here 
https://issues.apache.org/jira/servicedesk/customer/portal/1/create/3

In the meantime you could create a specific buildbot folder in your email client and a rule to send buildbot emails there (mails come from 
build...@apache.org, easy)


Jacques


Le 24/10/2017 à 12:57, Taher Alkhateeb a écrit :

Buildbot messages should not be too many, having that many is a faulty
implementation (false positives)

So, perhaps we shouldn't necessarily move the notifications away,
instead, we should fix the buildbot scripts.

On Tue, Oct 24, 2017 at 1:32 PM, James Yong  wrote:

Hi all,

The Buildbot messages are filling considerable spaces in the DEV mailing list.
Wonder if we should move them elsewhere...

Regards,
James Yong

Re: Tracking Data Model changes

[Aditya Sharma]

Hello all,

I have created a ticket here
.

I will be adding information about data model changes between OFBiz.9 to
OFBiz.17.11 in the initial file.

As commented on the ticket,

The file will have the format:


Entity Changes:

Here we will have a bulleted list with entity names and the revision number
1. Added Entities
2. Removed Entities


Field changes:

Here we will show data in tabular form in following format:

entityname | field | action | isPK | revision


Any suggestions are warmly welcomed.

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Thu, Oct 12, 2017 at 3:02 AM, Michael Brohl 
wrote:

> +1 for tracking datamodel changes together with data migration scripts
>
> In our customer projects, we track every change in a simple text file in
> the source code repository. It contains description of the changes,
> references to issues or requirement documentation and SQL scripts for
> migrations.
>
> In OFBiz, we should at least provide SQL scripts for the embedded Derby
> database, maybe there will be contributions for other databases as well.
>
> Something like db-changelog.derby.txt, db-changelog.mysql.txt or similar.
>
> Cheers,
>
> Michael
>
> Am 31.08.17 um 12:32 schrieb Taher Alkhateeb:
>
> Hi Ashish,
>>
>> With respect to Jacques' question, I kind of already answered in that
>> it is not only documentation but also automation.
>>
>> Now with respect to which releases to incorporate, it really depends
>> on what the community decides. I would personally prefer to not go any
>> earlier than 13, or preferably just 16 to trunk, which means we design
>> this solution for the future, not necessarily the past. The powerful
>> thing in using something like liquibase is that not only do you change
>> the schema (the entity engine can do that partially) but you also
>> decide on how to migrate the existing data to the new schema. For
>> example, you might need to split a field to two, or merge two fields,
>> and so on and so forth.
>>
>> Anyway, this is only an idea if people are interested in it. The
>> original idea of just documenting is also perfectly reasonable and
>> beneficial.
>>
>> On Thu, Aug 31, 2017 at 8:11 AM, Ashish Vijaywargiya
>>  wrote:
>>
>>> +1, Taher. I will wait for your comment on Jacques question, we already
>>> have a document but I think the automated script that can be implemented
>>> here. Liquidbase and flyway seem to be promising solutions!
>>>
>>> One question always comes to my mind: Can we say that automated scripts
>>> will support the migration from last two or at max three known releases?
>>> I think we should not put the effort in building the migration script
>>> that
>>> could migrate ofbiz earlier version(Let's say Ofbiz 10 or 9 or 4) to the
>>> latest version. Please share your thoughts on this.
>>>
>>> Kind Regards
>>> Ashish Vijaywargiya
>>> HotWax Systems - est. 1997 
>>>
>>>
>>> On Wed, Aug 30, 2017 at 7:54 PM, Taher Alkhateeb <
>>> slidingfilame...@gmail.com
>>>
 wrote:
 Good idea! Why not take it a step further, and write data migration
 scripts? They will serve two purposes in one: 1) document changes 2)
 automate upgrades.

 You can experiment with solutions like liquibase or flyway

 On Aug 30, 2017 4:23 PM, "Aditya Sharma" 
 wrote:

 Hello everyone,

 For one of my assignments, I need to find out entity changes that took
 place between an older release and the latest release.

 One of the solutions that came up was comparing the database using MySQL
 Workbench or some other utility. I found around 60+ new entity changes
 and
 a lot of minor field changes since last big book was published (OFBiz 9
 I
 suppose).
 It's fascinating for me that around 8 years passed since then and data
 model still stands well (Kudos to Universal Data Model that we followed
 in
 OFBiz)


 Just a proposal, since we don't have so many frequent changes in the
 data
 model. It will be good to have a page or some other method defined to
 keep
 a track of such changes.

 I feel such information can be quite helpful when migrating from an
 older
 to some newer release.

 Please share your thoughts.

 Thanks and Regards,

 *Aditya Sharma* | Enterprise Software Engineer
 HotWax Systems 
 


>
>