Re: OFBiz 16.11.01 docker demo-data image

[Jacques Le Roux]

Le 24/01/2017 à 22:04, Taher Alkhateeb a écrit :

  Mind you, however, that people still need to learn
how to install Docker (not yet very trivial on Linux) and they also still
need to get comfortable with docker commands and concepts.

And what about developers working on Windows like me? I'm not talking about 
Windows servers of course.

Jacques

Re: Multiple Subsidiaries in OfBiz

[Mridul Pathak]

Hello James,

Yes, multiple companies can be setup in OFBiz and independent company
management (accounting, ordering, warehousing, procuring, etc) is
achievable. Please seem my comments inline.

Thanks & Regards
Mridul Pathak
Hotwax Systems
http://www.hotwaxsystems.com 

On Tue, Jan 24, 2017 at 4:28 AM,  wrote:

> Hi all I am new to this group so hopefully I am posting in the correct
> areas.  We would like to set up OfBiz with Multiple Companies that all
> roll up into a Parent Company.  We are looking for the following:
>
> Separate Vendors (CRM tied to a separate company)
> Separate Customers (CRM tied to a seperate company
> Sales Associates can be tied to multiple companies
>

All of the above can be configured using PartyRelationship.


> Each company can fulfill from each others warehouse (intercompany
> transaction)
>
Should be able to invoice each other
>

You should be able to maintain inter company customer/supplier
relationships and raise SOs and POs.


> Warehouses should be tied to a company
> Stores should be tied to a company
> Financials Should be tied to a company
> Purchases Should be tied to a company
> Each company could have separate currency
> Each company could have separate language
>

With correct setup specific to each company above items could be achieved
easily. Following are few entities involved in configuration.
1) Party (Company in internal organization role)
2) PartyAcctgPreferences (Specific to each company)
3) GL setup specific to each company
4) ProductStore setup tied to the specific company
5) Facility (Warehouse) setup for each company. A company could be setup as
warehouse owner.


>
> We can use external reporting to handle the Intercompany consolidation
>

That should be a good approach.


>
> My question is does Ofbiz handle this OTB?  If so what are the key areas
> we need to configure for this to handle properly.
>

In essence it all depends on data modeling. If standard approach with
proper understanding of OFBiz data model and API is followed then pretty
much all the OOTB workflows should execute as expected.


>
> Thanks in Advance.
>
> James
> Productive One
>

Re: Multiple Subsidiaries in OfBiz

[Divesh Dutta]

I will say OFBiz handles most of this out of the box.

Thanks
--
Divesh

On Tue, Jan 24, 2017 at 4:28 AM,  wrote:

> Hi all I am new to this group so hopefully I am posting in the correct
> areas.  We would like to set up OfBiz with Multiple Companies that all
> roll up into a Parent Company.  We are looking for the following:
>
> Separate Vendors (CRM tied to a separate company)
> Separate Customers (CRM tied to a seperate company
> Sales Associates can be tied to multiple companies
> Each company can fulfill from each others warehouse (intercompany
> transaction)
> Should be able to invoice each other
> Warehouses should be tied to a company
> Stores should be tied to a company
> Financials Should be tied to a company
> Purchases Should be tied to a company
> Each company could have separate currency
> Each company could have separate language
>
> We can use external reporting to handle the Intercompany consolidation
>
> My question is does Ofbiz handle this OTB?  If so what are the key areas
> we need to configure for this to handle properly.
>
> Thanks in Advance.
>
> James
> Productive One
>

Re: OFBiz 16.11.01 docker demo-data image

[Shi Jinghai]

On the Solr, I guess Paul wants to separate read/write in some cases. Besides 
this, we also use Solr to offer exchange data to/from other systems (middle 
database), as an EDI interface as well.

-邮件原件-
发件人: Paul Mandeltort [mailto:p...@marcospec.com] 
发送时间: 2017年1月25日 7:05
收件人: user@ofbiz.apache.org
主题: Re: OFBiz 16.11.01 docker demo-data image

Full disclosure, I am relatively new to docker and containerization technology, 
and only have deployments on my staging servers at the moment, so my main goal 
here is to just facilitate discussion and get the group thinking about it from 
an end/user small-shop ops perspective! :-) 

> On Jan 24, 2017, at 3:04 PM, Taher Alkhateeb  
> wrote:
> 
> Hi Paul, Thank you for your thoughts, inline ...
> 
> On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort  wrote:
> 
>> Just skimmed it. It’s an excellent overview for folks familiar with 
>> IT ops and virtual environments and covers some of the key architectural 
>> bits.
>> 
>> As it applies to OFbiz, I foresee containerized ofbiz deployments to 
>> look
>> like:
>> 
>> - Application Container
>>- Base OOTB OFBiz container
>>- User-specified plugins/extra layers
>>- Company-specific logic and code layer
>> - Search Engine Container
>>- SOLR and related configurations
>> 
> 
> Hmmm, why a container here? Why not just a regular plugin pulled to 
> the code base?

Assuming you’re talking about SOLR here? SOLR itself is a standalone service 
that can often grow and be partitioned on its own, it makes sense in the 
containerization ideology to keep that image separate and in its own 
application server.  This also makes it easier to scale and optimize in 
deployment scenarios.  I can recall several instances, at least in the Lucene 
days of OFbiz, where we had indexing configured incorrectly and accidentally 
triggered re-indexing operations that ended up consuming the entire application 
container and crashing/locking up the system (due partially to our lousy 
design). Pulling out this container and having it run separately makes the 
application more resilient, and lets administrators easily tweak performance 
priorities. 

> - Database Engine Container
>>- A standard Postgres instance optimized for OFbiz
>>- User-configured database configuration container
>> - Demo-Data volume container
>>- Standard data volume pre-loaded with OFBiz demo data
>> 
> 
> Volume containers are sort of deprecated now. They were a work around 
> in the early days of Docker before managed volumes were introduced. In 
> fact managed volumes would make your life easier as you can quickly 
> reset your environment with: ./docker rm -fv $(docker ps -q) and that 
> would remove everything including the managed volumes.

Agreed, my terminology was wrong. :-) I was referring to managed volumes. 
Either way having the database container separate means we can just switch the 
configuration (via configuration volumes which can also be managed) to point to 
Amazon RDS or existing company database infrastructure. 

Configuration management in OFbiz has always been a pain with the various 
.properties files running around everywhere.  Locking all of that into a known 
good configuration image would greatly help deployments and versioning of 
systems. 

> 
>> As I understand it, the only reason OFBiz doesn’t ship OOTB in this 
>> configuration is that it’s a pain in the ass to configure and test quickly.
>> I know I’ve wasted hours in the past setting up an instance of 
>> Postgres because I forget how to get Postgres ports configured 
>> correctly, or run into firewall issues on the linux host I’m using, 
>> or user accounts, or permissions, or whatever. Containers eliminate all of 
>> those problems.
>> 
>> It’s theoretically possible to do a docker run apache/ofbiz:latest 
>> (I’m dreaming here, no official builds for ofbiz on docker hub, yet!) 
>> and have an entire IT-ready demo-data-pre-loaded system of ofbiz 
>> launch on any developer machine or production environment.
>> 
> 
> Yeah that's very doable, the Dockerfile would be trivial too. We can 
> start from an image like "airdock/oracle-jdk", load gradle, pull 
> dependencies into cache, load data, and then set the CMD to ./gradlew 
> ofbizBackground.
> Probably /runtime should be exposed as a managed volume.

This is basically what the demo-test Dockerfile I hacked together looks like. 
Still fiddling with which volumes to expose but the version I posted on docker 
hub exposes /ofbiz/runtime/data and /ofbiz/framework/entity/config. 

>> Architecturally, I’d like to put the idea out there that OFBiz should 
>> to switch to containerization from ground up.  Having worked with 
>> OFBiz for some years now, all of the major pain points I’ve had with 
>> OFBiz have been related to configuration, deployment, and iteration 
>> speed. All of these issues are soundly addressed by containerization. 
>> If the OFBiz team jumps on this revolution

Re: OFBiz 16.11.01 docker demo-data image

[Paul Mandeltort]

Full disclosure, I am relatively new to docker and containerization technology, 
and only have deployments on my staging servers at the moment, so my main goal 
here is to just facilitate discussion and get the group thinking about it from 
an end/user small-shop ops perspective! :-) 

> On Jan 24, 2017, at 3:04 PM, Taher Alkhateeb  
> wrote:
> 
> Hi Paul, Thank you for your thoughts, inline ...
> 
> On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort  wrote:
> 
>> Just skimmed it. It’s an excellent overview for folks familiar with IT ops
>> and virtual environments and covers some of the key architectural bits.
>> 
>> As it applies to OFbiz, I foresee containerized ofbiz deployments to look
>> like:
>> 
>> - Application Container
>>- Base OOTB OFBiz container
>>- User-specified plugins/extra layers
>>- Company-specific logic and code layer
>> - Search Engine Container
>>- SOLR and related configurations
>> 
> 
> Hmmm, why a container here? Why not just a regular plugin pulled to the
> code base?

Assuming you’re talking about SOLR here? SOLR itself is a standalone service 
that can often grow and be partitioned on its own, it makes sense in the 
containerization ideology to keep that image separate and in its own 
application server.  This also makes it easier to scale and optimize in 
deployment scenarios.  I can recall several instances, at least in the Lucene 
days of OFbiz, where we had indexing configured incorrectly and accidentally 
triggered re-indexing operations that ended up consuming the entire application 
container and crashing/locking up the system (due partially to our lousy 
design). Pulling out this container and having it run separately makes the 
application more resilient, and lets administrators easily tweak performance 
priorities. 

> - Database Engine Container
>>- A standard Postgres instance optimized for OFbiz
>>- User-configured database configuration container
>> - Demo-Data volume container
>>- Standard data volume pre-loaded with OFBiz demo data
>> 
> 
> Volume containers are sort of deprecated now. They were a work around in
> the early days of Docker before managed volumes were introduced. In fact
> managed volumes would make your life easier as you can quickly reset your
> environment with: ./docker rm -fv $(docker ps -q) and that would remove
> everything including the managed volumes.

Agreed, my terminology was wrong. :-) I was referring to managed volumes. 
Either way having the database container separate means we can just switch the 
configuration (via configuration volumes which can also be managed) to point to 
Amazon RDS or existing company database infrastructure. 

Configuration management in OFbiz has always been a pain with the various 
.properties files running around everywhere.  Locking all of that into a known 
good configuration image would greatly help deployments and versioning of 
systems. 

> 
>> As I understand it, the only reason OFBiz doesn’t ship OOTB in this
>> configuration is that it’s a pain in the ass to configure and test quickly.
>> I know I’ve wasted hours in the past setting up an instance of Postgres
>> because I forget how to get Postgres ports configured correctly, or run
>> into firewall issues on the linux host I’m using, or user accounts, or
>> permissions, or whatever. Containers eliminate all of those problems.
>> 
>> It’s theoretically possible to do a docker run apache/ofbiz:latest (I’m
>> dreaming here, no official builds for ofbiz on docker hub, yet!) and have
>> an entire IT-ready demo-data-pre-loaded system of ofbiz launch on any
>> developer machine or production environment.
>> 
> 
> Yeah that's very doable, the Dockerfile would be trivial too. We can start
> from an image like "airdock/oracle-jdk", load gradle, pull dependencies
> into cache, load data, and then set the CMD to ./gradlew ofbizBackground.
> Probably /runtime should be exposed as a managed volume.

This is basically what the demo-test Dockerfile I hacked together looks like. 
Still fiddling with which volumes to expose but the version I posted on docker 
hub exposes /ofbiz/runtime/data and /ofbiz/framework/entity/config. 

>> Architecturally, I’d like to put the idea out there that OFBiz should to
>> switch to containerization from ground up.  Having worked with OFBiz for
>> some years now, all of the major pain points I’ve had with OFBiz have been
>> related to configuration, deployment, and iteration speed. All of these
>> issues are soundly addressed by containerization. If the OFBiz team jumps
>> on this revolution, it could quickly spring to the forefront of ERP
>> technologies since containerization is that powerful.
>> 
> 
> I think the main value of containerization is standardization of deployment
> and independence of machines and virtual machines, but not much more than
> that. The pain is still here because we still need to "think" about
> structuring our data and different deployment variati

Re: OFBiz 16.11.01 docker demo-data image

[Taher Alkhateeb]

Hi Paul, Thank you for your thoughts, inline ...

On Tue, Jan 24, 2017 at 9:02 PM, Paul Mandeltort  wrote:

> Just skimmed it. It’s an excellent overview for folks familiar with IT ops
> and virtual environments and covers some of the key architectural bits.
>
> As it applies to OFbiz, I foresee containerized ofbiz deployments to look
> like:
>
> - Application Container
> - Base OOTB OFBiz container
> - User-specified plugins/extra layers
> - Company-specific logic and code layer
> - Search Engine Container
> - SOLR and related configurations
>

Hmmm, why a container here? Why not just a regular plugin pulled to the
code base?

- Database Engine Container
> - A standard Postgres instance optimized for OFbiz
> - User-configured database configuration container
> - Demo-Data volume container
> - Standard data volume pre-loaded with OFBiz demo data
>

Volume containers are sort of deprecated now. They were a work around in
the early days of Docker before managed volumes were introduced. In fact
managed volumes would make your life easier as you can quickly reset your
environment with: ./docker rm -fv $(docker ps -q) and that would remove
everything including the managed volumes.


> As I understand it, the only reason OFBiz doesn’t ship OOTB in this
> configuration is that it’s a pain in the ass to configure and test quickly.
> I know I’ve wasted hours in the past setting up an instance of Postgres
> because I forget how to get Postgres ports configured correctly, or run
> into firewall issues on the linux host I’m using, or user accounts, or
> permissions, or whatever. Containers eliminate all of those problems.
>
> It’s theoretically possible to do a docker run apache/ofbiz:latest (I’m
> dreaming here, no official builds for ofbiz on docker hub, yet!) and have
> an entire IT-ready demo-data-pre-loaded system of ofbiz launch on any
> developer machine or production environment.
>

Yeah that's very doable, the Dockerfile would be trivial too. We can start
from an image like "airdock/oracle-jdk", load gradle, pull dependencies
into cache, load data, and then set the CMD to ./gradlew ofbizBackground.
Probably /runtime should be exposed as a managed volume.


> Architecturally, I’d like to put the idea out there that OFBiz should to
> switch to containerization from ground up.  Having worked with OFBiz for
> some years now, all of the major pain points I’ve had with OFBiz have been
> related to configuration, deployment, and iteration speed. All of these
> issues are soundly addressed by containerization. If the OFBiz team jumps
> on this revolution, it could quickly spring to the forefront of ERP
> technologies since containerization is that powerful.
>

I think the main value of containerization is standardization of deployment
and independence of machines and virtual machines, but not much more than
that. The pain is still here because we still need to "think" about
structuring our data and different deployment variations. I found it
painful to write some of the Dockerfiles for example, and also figuring out
all the docker commands needed to set things up correctly. Docker Compose
helps a little bit, but you're still left with lots of configurations to
sort out.


> In a containerized OFBiz world, we could lose Derby completely as it’s
> useless in production and only used because it’s easy to configure and
> deploy. Postgres has emerged as de facto standard Open Source database, and
> is scalable to enterprise applications but also packable OOTB now with
> Docker.
>

Good idea, I thought about the same thing, replace derby with a production
scale DB in a container. Mind you, however, that people still need to learn
how to install Docker (not yet very trivial on Linux) and they also still
need to get comfortable with docker commands and concepts. It took me quite
some time to finally get the light-bulb on the real difference between
containers and VMs (VERY different).

So in short, I think docker is an excellent tool, I would recommend though
taking an evolutionary approach instead of a revolutionary one. We can
start by defining some images on docker hub, maybe adding a Dockerfile into
the code base with updates to README.md for quick docker deployments, and
then we take it from there.


>
> We also lose Java version and OS dependency problems - if OFbiz
> deployments were standardized in a containerized world, then the OFBiz
> tested image will always have the correct versions of everything in it, so
> next time a Heartbleed like vulnerability is discovered that affects
> OS-level components like OpenSSL, upgrading becomes trivial.
>
> Odoo (formerly OpenERP), arguably the main OFBiz competitor, is already on
> Dockerhub and has their automated builds publishing their images
> automatically have a look at how they are doing it:
> https://hub.docker.com/r/_/odoo/ 
>
> —P
>
> > On Jan 24, 2017, at 10:35 AM, Todd Thorner

Re: OFBiz 16.11.01 docker demo-data image

[Paul Mandeltort]

Just skimmed it. It’s an excellent overview for folks familiar with IT ops and 
virtual environments and covers some of the key architectural bits.
 
As it applies to OFbiz, I foresee containerized ofbiz deployments to look like: 

- Application Container
- Base OOTB OFBiz container
- User-specified plugins/extra layers
- Company-specific logic and code layer
- Search Engine Container
- SOLR and related configurations 
- Database Engine Container
- A standard Postgres instance optimized for OFbiz
- User-configured database configuration container 
- Demo-Data volume container
- Standard data volume pre-loaded with OFBiz demo data

As I understand it, the only reason OFBiz doesn’t ship OOTB in this 
configuration is that it’s a pain in the ass to configure and test quickly. I 
know I’ve wasted hours in the past setting up an instance of Postgres because I 
forget how to get Postgres ports configured correctly, or run into firewall 
issues on the linux host I’m using, or user accounts, or permissions, or 
whatever. Containers eliminate all of those problems.  

It’s theoretically possible to do a docker run apache/ofbiz:latest (I’m 
dreaming here, no official builds for ofbiz on docker hub, yet!) and have an 
entire IT-ready demo-data-pre-loaded system of ofbiz launch on any developer 
machine or production environment. 

Architecturally, I’d like to put the idea out there that OFBiz should to switch 
to containerization from ground up.  Having worked with OFBiz for some years 
now, all of the major pain points I’ve had with OFBiz have been related to 
configuration, deployment, and iteration speed. All of these issues are soundly 
addressed by containerization. If the OFBiz team jumps on this revolution, it 
could quickly spring to the forefront of ERP technologies since 
containerization is that powerful. 

In a containerized OFBiz world, we could lose Derby completely as it’s useless 
in production and only used because it’s easy to configure and deploy. Postgres 
has emerged as de facto standard Open Source database, and is scalable to 
enterprise applications but also packable OOTB now with Docker.  

We also lose Java version and OS dependency problems - if OFbiz deployments 
were standardized in a containerized world, then the OFBiz tested image will 
always have the correct versions of everything in it, so next time a Heartbleed 
like vulnerability is discovered that affects OS-level components like OpenSSL, 
upgrading becomes trivial.  

Odoo (formerly OpenERP), arguably the main OFBiz competitor, is already on 
Dockerhub and has their automated builds publishing their images automatically 
have a look at how they are doing it: 
https://hub.docker.com/r/_/odoo/ 

—P

> On Jan 24, 2017, at 10:35 AM, Todd Thorner  wrote:
> 
> For those OFBiz end users who might be interested, there exists a free (with 
> registration) e-book that covers containerizing traditional applications.  I 
> haven't read it yet, so this can't be a direct endorsement.
> 
> 
> http://info.nirmata.com/containerizing-traditional-apps-ebook?hsCtaTracking=09d8e4bd-2cfa-401f-8534-90f19e6ba312|3ddcaf2a-01e7-4ea7-9adb-2ba1c7033753&__hstc=52585783.0993e39ff53fa9e412248fb800e32a02.1485203112635.1485203112635.1485203112635.1&__hssc=52585783.1.1485203112635&__hsfp=null
>  
> 
> 
> 
> 
> On 17-01-17 12:34 PM, Paul Mandeltort wrote:
>> CoreOS goes hand-in-hand with Docker - it’s designed for deploying Docker on 
>> production bare metal servers.
>> 
>> I’ve been experimenting with CoreOS for our internal servers and overall 
>> it’s an awesome OS simply because updates and security are architected in. 
>> Keep in mind it’s designed for cloud deployments so getting it going the 
>> first time is a bit tricky.
>> 
>> CoreOS is just a lightweight cloud-scalable replacement for your bare metal 
>> OS layer. It’s just as compatible with OFbiz as any other Linux OS. If it 
>> runs the JVM well, it’ll run OFBiz well (generally speaking, this is an 
>> optimistic simplification). I haven’t completed any significant validation 
>> testing on CoreOS yet but so far I don’t see any major showstoppers.
>> 
>> So a modern in-house stack might look like:
>> Bare Metal Server
>> Virtualization OS (Xen, VMware, VirtualBox, etc)
>> CoreOS for Docker Host OS (or Ubuntu or CentOS or RancherOS)
>> Docker
>> Application Docker Image
>> Debian/Ubuntu/Alpine essential OS components
>> JVM - OpenJDK
>> Tomcat
>> OFBiz Application Layer
>> Database Docker Image
>> Debian/Ubuntu/Alpine essential OS components
>> PostgreSQL
>> Data over NFS to NAS appliance or cloud hosting disk
>> Web Proxy Image 

Re: OFBiz 16.11.01 docker demo-data image

[Todd Thorner]

For those OFBiz end users who might be interested, there exists a free 
(with registration) e-book that covers containerizing traditional 
applications.  I haven't read it yet, so this can't be a direct endorsement.



http://info.nirmata.com/containerizing-traditional-apps-ebook?hsCtaTracking=09d8e4bd-2cfa-401f-8534-90f19e6ba312|3ddcaf2a-01e7-4ea7-9adb-2ba1c7033753&__hstc=52585783.0993e39ff53fa9e412248fb800e32a02.1485203112635.1485203112635.1485203112635.1&__hssc=52585783.1.1485203112635&__hsfp=null



On 17-01-17 12:34 PM, Paul Mandeltort wrote:

CoreOS goes hand-in-hand with Docker - it’s designed for deploying Docker on 
production bare metal servers.

I’ve been experimenting with CoreOS for our internal servers and overall it’s 
an awesome OS simply because updates and security are architected in. Keep in 
mind it’s designed for cloud deployments so getting it going the first time is 
a bit tricky.

CoreOS is just a lightweight cloud-scalable replacement for your bare metal OS 
layer. It’s just as compatible with OFbiz as any other Linux OS. If it runs the 
JVM well, it’ll run OFBiz well (generally speaking, this is an optimistic 
simplification). I haven’t completed any significant validation testing on 
CoreOS yet but so far I don’t see any major showstoppers.

So a modern in-house stack might look like:
Bare Metal Server
Virtualization OS (Xen, VMware, VirtualBox, etc)
CoreOS for Docker Host OS (or Ubuntu or CentOS or RancherOS)
Docker
Application Docker Image
Debian/Ubuntu/Alpine essential OS components
JVM - OpenJDK
Tomcat
OFBiz Application Layer
Database Docker Image
Debian/Ubuntu/Alpine essential OS components
PostgreSQL
Data over NFS to NAS appliance or cloud hosting disk
Web Proxy Image (apache/nginx)
Debian/Ubuntu/Alpine essential OS components
Bare Metal NAS appliance (no point in virtualizing data stores, just adds 
overhead).
Sounds complex, but the major paradigm shift here is packaging up the OS 
specific components with your release and version-controlling the system as a 
whole rather than just the application layer component. In this new model, you 
deploy specific versions of OFBiz with a specific version of the JVM, a 
specific version of the application OS, and even a specific version of the 
database.  Moving a Docker image to a cloud host is very easy now, so you can 
easily have your developers working on the complete versioned stack on their 
machines, check the whole stack in to github/dockerhub, deploy it to your test 
servers, then just slap those docker images live on your cloud hosts once 
everything is verified with no surprises.

If I was working on a new deployment, going cloud-hosted for everything is a 
no-brainer these days.

The paradigm that the entire industry is rushing towards is treating IT 
resources (servers, OSs, deployments, etc) as cattle, not pets:
http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ 


If OFbiz were to get behind this paradigm (and this is a whole different 
discussion probably for the developers but I’m just advocating from an end 
user’s point of view), we could easily decouple the heavier components and have 
them versioned as docker images separately. For example, an OFBiz release would 
be a collection of docker images - one for SOLR, one for Postgres, one for 
Tomcat, and one for the OFBiz application layers.

—P


On Jan 17, 2017, at 1:41 PM, Todd Thorner  wrote:

Great stuff, thanks.

Have you any opinion on leaping straight toward something like CoreOS?  Is the 
difference mostly a matter of codebase maturity, or is it something more 
fundamental to the design/architecture which might leave docker as being more 
compatible with OFBiz?


- Todd



On 17-01-17 10:23 AM, Paul Mandeltort wrote:

Hey guys, thought you’d be interested in a side project I’ve been working on to 
smooth out our devops. One of the biggest pain points for me in OFbiz 
development and deployment (as an end user) is managing the complex 
dependencies and differences between JDK’s, OS’s, hardware platforms, etc. 
Docker solves all of these problems.

Even spinning up a demo of OFBiz is needlessly complicated in a world where I 
can hop on the app store and have an application as complex as Apple Xcode 
installed on my local with one click.

Docker is as big of a revolution as virtualization for development and 
deployment, and is taking over the IT dev-ops and development world.

I noticed several other OFBiz docker projects on dockerhub but none of them 
have been updated for the 16.11.01 release.

Have a look here - I preloaded a copy of the ofbiz 16.11.01 release with the 
demo data for immediate download and execution. You can start up ofbiz in under 
5 minutes now (Depending on your internet bandwidth). This is ideal for any 
folks evaluating ofbiz or want a quick copy to hack at.

https://hub.docker.com/r/marcopinball/ofbiz-demo/ 

OFBiz Mini Conference for Apachecon NA Miami ?

[Sharan Foga]

Hi Everyone

I'm not sure if you've seen the messages promoting Apachecon NA in Miami in 
May. Anyone can submit a presentation for the event and if we have enough 
submissions we may be able to put together an OFBiz track. We've had successful 
OFBiz tracks in the past and it's been a great opportunity to get the community 
together and collaborate.

Another possible option that I wanted to get feedback from the community about 
is whether people would be interested in having a co-located OFBiz mini 
conference at Apachecon as a separate event. 

I know that a few ASF projects are looking to hold  mini-conferences in Miami 
so wondered if our community was interested in doing that too. I think that one 
advantage could be being able to have more business based presentations / 
tutorials etc/ training  so that existing or potential OFBiz users / customers 
could also come along to something more OFBiz focussed. 

Anyway I'm not sure what the community interest is and if we would have enough 
attendees to make a separate event it worth while.

So please let me know what you think.

Thanks
Sharan 

create company

[Moatasim Al Masri]

Hi friend
I have issue in ofbiz 16.11.01 when I create new party group which is company 
not displayed in main hr page and also I granted role Internal Organization !!

Could anybody have answer please?

Recall: create company

[Moatasim Al Masri]

Moatasim Al Masri would like to recall the message, "create company".

create company

[Moatasim Al Masri]

Hi friend
I have issue in ofbiz 10.11.01 when I create new party group which is company 
not displayed in main hr page and also I granted role Internal Organization !!

Could anybody have answer please?

Multiple Subsidiaries

[james]

Hi all I am new to this group so hopefully I am posting in the correct
areas. We would like to set up OfBiz with Multiple Companies that all
roll up into a Parent Company. We are looking for the following:

Separate Vendors (CRM tied to a separate company)
Separate Customers (CRM tied to a seperate company
Sales Associates can be tied to multiple companies
Each company can fulfill from each others warehouse (intercompany
transaction)
Should be able to invoice each other
Warehouses should be tied to a company
Stores should be tied to a company
Financials Should be tied to a company
Purchases Should be tied to a company
Each company could have separate currency
Each company could have separate language

We can use external reporting to handle the Intercompany consolidation

My question is does Ofbiz handle this OTB? If so what are the key areas
we need to configure for this to handle properly.

Thanks in Advance.

James
Productive One

Re: a vendor

[Heidi Dehaes - Olagos]

thanks,
Eric

Olagos bvba
Heidi Dehaes
Kerkstraat 34
2570 Duffel
Belgium
Tel. : 015/31 53 04
GSM :0485/22 35 80
E-mail : info.ola...@gmail.com
http://www.olagos.eu
http://www.olagos.com
http://www.olagos.be
http://www.olagos.nl



2017-01-24 9:17 GMT+01:00 Wei Zhang :

> See http://ofbiz.135035.n4.nabble.com/vendors-and-suppliers-td4168824.html
>
>
>
> -
> 程序羊
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/a-vendor-
> tp4701312p4701314.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

Multiple Subsidiaries in OfBiz

[james]

Hi all I am new to this group so hopefully I am posting in the correct
areas.  We would like to set up OfBiz with Multiple Companies that all
roll up into a Parent Company.  We are looking for the following:

Separate Vendors (CRM tied to a separate company)
Separate Customers (CRM tied to a seperate company
Sales Associates can be tied to multiple companies
Each company can fulfill from each others warehouse (intercompany
transaction)
Should be able to invoice each other
Warehouses should be tied to a company
Stores should be tied to a company
Financials Should be tied to a company
Purchases Should be tied to a company
Each company could have separate currency
Each company could have separate language

We can use external reporting to handle the Intercompany consolidation

My question is does Ofbiz handle this OTB?  If so what are the key areas
we need to configure for this to handle properly.

Thanks in Advance.

James
Productive One

Re: a vendor

[Wei Zhang]

See http://ofbiz.135035.n4.nabble.com/vendors-and-suppliers-td4168824.html



-
程序羊
--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/a-vendor-tp4701312p4701314.html
Sent from the OFBiz - User mailing list archive at Nabble.com.