p2ee-devel — Developers of p2ee applications

Re: [p2ee-devel] P2EE Development Environment Setup

[p2ee l. f. d. <p2e...@li...>]

All p2ee files are in UTF-8

What could be happening is that PgSQL is installed with a weird locale
in Ubuntu by default. It's usually best for PgSQL to have C locale in
it's base and then you can put anything on top of that. I will try to
replicate on Ubuntu later today and see if I get the same error.

Also, you can Download p2eeDE from sf.net and it works right off the
bat. It's a Debian virtual machine (no X) with everything installed
and working.

-- 
Alejandro

On Fri, Feb 10, 2012 at 12:03 AM, p2ee list for developers
<p2e...@li...> wrote:
> Hello All,
>
> I tried setting up the dev environment and I found an issue with
> creating database schema. The file definition.sql created by 'gen_db.sh'
> contains non UTF8 characters and psql fails to run the SQL with
> following error -
>
> psql:./definition.sql:11: ERROR:  invalid byte sequence for encoding
> "UTF8": 0xf0e38b29
> ...
>
> Please note that I've checked out SVN and I'm running this from trunk.
>
> I'm running this on Ubuntu 10.10 with PostGreSQL version 9.0. The
> definition.sql if created by dia2code but I'm not sure why the output
> encoding is other than UTF8. Appreciate any help on this.
>
> Thanks,
> Rajesh
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> p2ee-devel mailing list
> p2e...@li...
> https://lists.sourceforge.net/lists/listinfo/p2ee-devel

[p2ee-devel] P2EE Development Environment Setup

[p2ee l. f. d. <p2e...@li...>]

Hello All,

I tried setting up the dev environment and I found an issue with 
creating database schema. The file definition.sql created by 'gen_db.sh' 
contains non UTF8 characters and psql fails to run the SQL with 
following error -

psql:./definition.sql:11: ERROR:  invalid byte sequence for encoding 
"UTF8": 0xf0e38b29
...

Please note that I've checked out SVN and I'm running this from trunk.

I'm running this on Ubuntu 10.10 with PostGreSQL version 9.0. The 
definition.sql if created by dia2code but I'm not sure why the output 
encoding is other than UTF8. Appreciate any help on this.

Thanks,
Rajesh

[p2ee-devel] p2ee in 2012

[p2ee l. f. d. <p2e...@li...>]

Hello to all and I hope that 2012 brings all of you a great year!

It's definitively going to be an exciting time at p2ee because
Yabarana will start pouring back all the developments od YARA to p2ee.
One of the most exciting things will be how p2ee resources will be
standardized in RDF and this will put p2ee at the forefront of
Enterprise Systems.


For further details, see the news section on our Wiki.


Best,

-- 
Alejandro Imass

[p2ee-devel] One more thing...

[p2ee l. f. d. <p2e...@li...>]

On the technical side I forgot to mention that we will adhere to JSON
Schema or Orderly JSON for p2ee entities.

Best,
Alex

[p2ee-devel] Happy New Year !

[p2ee l. f. d. <p2e...@li...>]

Happy new year everyone!

This is a short note to keep you update on where p2ee is now and where
it's heading.

2010
-------
Last year we stopped the functionality of the alpha Inventory
application to revise the overall architecture, code structure etc.
We released a development Virtual Machine on SourceForge for anyone to
download and play with.
With the preliminary results of the alpha Inventory application and
lessons learned with p2ee development, our primary sponsor decided to
invest heavily in architectural design and has been working on a
internal project called YARA.

Some YARA Facts it's relationship to p2ee
-------------------------------------------------------
Yabarana presented YARA with awesome feedback at NASA's KSC Business
Expo in late 2010.
Yabarana agreed to invest to re-write p2ee using the YARA technology
stack, but will not reveal what actually constitutes YARA within p2ee.
YARA's deployment techniques for Internet-scale applications are
mostly what Yabarana want's to protect as IP at this time, and it's
currently not clear whether YARA as such will remain an inside tool
for applications produced by Yabarana, or that it may aim to license
YARA technology to third parties. These decisions will be made based
on private investment rounds and capital funding starting early 2011.
Yabarana is committed to release any and all enhancements performed on
existing OSS software, and will continue to support, sponsor and
further develop p2ee applications, at least until the completion of
Inventory, Sales and Purchasing.
The bottom line is that p2ee will greatly benefit from the
architectural changes it will receive from Yabarana, meaning that
_standard_ deployments of p2ee applications will already be highly
scalable right off the bat, meaning possible business opportunities
for anyone for example interested in offering services around p2ee
applications or using p2ee directly. Yabarana may also offer
commercial p2ee support as well, or maybe support or partner with
other companies that may want to do so.
Anything released on the p2ee project is licensed under the terms of
Perl itself, so no worries there.

What's in store for p2ee in 2011
-----------------------------------------
Currently p2ee is only being maintained with Yabarana resources. Not a
decision by Yabarana but the general response of the public. We
released the VM in an effort to ease the entry-level and encourage
other developers to use and comment on the current p2ee alpha
application Inventory, but sadly we have had no feedback, except for
one person who seemed very eager and we never heard back from him
again.

p2ee will continue to evolve throughout 2011 depending mostly on
investment from capital investors, though Yabarana is committed to
continue to invest in p2ee regardless. If you are associated to any
capital investors this would be a good time to contact us both for
p2ee and YARA!

The biggest change that you will see is a clean-cut separation of the
write and read paths for p2ee resources. The write path will continue
through the p2ee libs using the DBIC model into Pg. But the read stack
will change to CouchDB. Triggers and Stored Procedures on Pg will
update the de-normalized resources to CouchDB. Fortunately, the change
in p2ee are really not that hard since the controllers that do this
are already in place, on the contrary it would be actually done by
removing all the read code from the resource controllers/model and
reads will go directly to CouchDB resources, even internal application
reads will not touch Pg but will fetch data from CouchDB, completely
separating the write and read stacks.

You will also see major changes in the Catalyst code itself. The p2ee
libs will be formalized as Catalyst models, and Workflow will be more
cleanly integrated as well. Things will get very Moosy, including a
potential re-write of WF in Moose, if we find the money for it, and if
WF maintainers agree with such a re-write. Functionality-wise will
probably not grow that much, although we will strive to finish the
Inventory application (currently > 90% functional-wise) at last!

I think that's all for now.

Best wishes for 2011,
Alejandro Imass

Re: [p2ee-devel] Size of P2EE

[p2ee l. f. d. <p2e...@li...>]

Hi Rajesh,

The size it's because it's a complete Debian-based Sun Virtual Box
machine with everything installed and working. It's targetted for
developers not for final users. I think you were the one that asked to
be in the project. I included you but never heard back from you until
now.

Here are the instructions to download and configure the Sun Virtual
Box. You can download the individual components of the VM as well.
Just open the folder in the SF download area and you can download each
disk indivdually, but you will wind up with 800 MB anyway ;-)

http://sourceforge.net/apps/mediawiki/p2ee/index.php?title=P2eeDE_install

We did that because people would tend to stay away from installing and
configuring everything needed to get this stuff running. A novice user
could take days to try to install and configure everything and still
have many problems after that. We are thinking to release a PAR after
the final re-write of the new p2ee (this will be done from here till
Dec)


On Fri, Oct 8, 2010 at 7:02 AM, p2ee list for developers
<p2e...@li...> wrote:
>  Hello Folks,
>
> I'm new to P2EE and while downloading it from Sourceforge, I noticed the
> size of tar ball is over 800 MB. This looks strange considering apache
> itself is around 6 MB in size.
>
> Not sure why is it so huge? Please let me know if I'm doing something
> wrong. I'm downloading p2eeDE.tar.
>
> Thanks
> -Rajesh
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> p2ee-devel mailing list
> p2e...@li...
> https://lists.sourceforge.net/lists/listinfo/p2ee-devel
>

[p2ee-devel] Size of P2EE

[p2ee l. f. d. <p2e...@li...>]

  Hello Folks,

I'm new to P2EE and while downloading it from Sourceforge, I noticed the 
size of tar ball is over 800 MB. This looks strange considering apache 
itself is around 6 MB in size.

Not sure why is it so huge? Please let me know if I'm doing something 
wrong. I'm downloading p2eeDE.tar.

Thanks
-Rajesh

[p2ee-devel] Instructions for Running the DE, Release Notes, etc.

[p2ee l. f. d. <p2e...@li...>]

Please refer to the p2eeDE Articles in the link below, for installing
and running the DE:

https://sourceforge.net/apps/mediawiki/p2ee/index.php?title=Documentation

[p2ee-devel] Support for the p2eeDE

[p2ee l. f. d. <p2e...@li...>]

Hi,

I see that people have started to download the p2eeDE!
Just wanted to remind you that support for the DE will be handled
through this list only.

We are posting some release notes, known bugs and limitations, as well
as the state of the current Inventory Application Demo.
Check the p2eeDE section in docs at the Wiki for more information.


Best,
Alex

[p2ee-devel] p2ee Development Environment Released !

[p2ee l. f. d. <p2e...@li...>]

Hello all,

I'm happy to inform that we have officially released our first version
of the p2ee Development Environment a.k.a. p2eeDE.

This is a complete, ready-to-use version of the current p2ee code and
runs on Oracle's VirtualBox (formerly Sun's).
It can probably be imported into VMWare or others at your risk.

Just download and run it. Simple.

All the instructions are here:

http://sourceforge.net/apps/mediawiki/p2ee/index.php?title=P2eeDE_install

Best,
Alex

[p2ee-devel] Status of the project - moving forward

[p2ee l. f. d. <p2e...@li...>]

Hi all,

Although it may seem that we are not doing much, we are actually
working very hard to take the project to the next step.

Funding has been a major issue but that _may_ soon change. As some of
you know, the main corporate sponsor is Yabarana Corporation in NY
(the company I work for) and we have only been able to dedicate very
limited resources to the p2ee project itself. Nevertheless, we have
dedicated vast amount of resources to the project's technology we have
branded as YARA, and will be formally unveiled  at NASA's Business
Expo 2010 on Tuesday, October 19, 2010, 9:00 a.m. - 3:00 p.m. Cruise
Terminal #3, Port Canaveral, FL  (http://expo.ksc.nasa.gov/), table
#55

For those of you who have had a chance to play with the p2ee code, you
will have probably noticed that the controller space is crowded with
stuff that should actually belong in a model, for example all the
Worlflow stuff. Furthermore, the p2ee controllers are not using action
classes or have a Catalyst plugin standard of any sort. If you look at
previous branches, you will see that this has evolved but never been
complete formalized in components and libraries that can make their
way to the CPAN. Other issues include very little testing,
definitively no TDD. Of course, this is expected as the current p2ee
trunk is still a proof of concept.

YARA in essence is just a formalization of p2ee's architecture. All
the components of YARA will be published on the CPAN, so don't worry
about the Open Source nature of the project. Some stuff will live on
the p2ee namespace and some on the YARA namespace on the CPAN. The
current p2ee trunk will be tagged in a new "poc" tag and the trunk
will be migrated to YARA. But BEFORE this will happen, we want to
complete the inventory poc, a long time objective that keeps slipping.
Another objective is the development virtual machine to lower the
entry barrier for people wanting to use, contribute or hack at p2ee.
Now that we have a corporate deadline, we are pretty confident the Sun
VirtualBox VM will be ready by the NASA Expo.

Well, that's all for now.

Best,
Alex

[p2ee-devel] Back on the saddle again!

[p2ee l. f. d. <p2e...@li...>]

Hello, hope this note finds everyone well.

This has been silent for a while now, and I want to apologize for
that. I think I might have put too much pressure to meet my own
imposed December deadlines. I burnt myself out which caused some sort
of rejection, besides the fact that no one seems to care anyway. I
reminded me of the time I ate a complete tray of avocado snacks when I
was about 8 years old, and could never even see avocado again for may
years after that, up until my early twenties! Anyway, the burns have
healed now so I will start working again to get Inventory out the door
soon, but on a "Wake me up when it's done mode !"

As always, any help and comments welcome.

Yours,
Alejandro Imass

Re: [p2ee-devel] Material Requests - 102 - Explained

[p2ee l. f. d. <p2e...@li...>]

On Thu, Feb 25, 2010 at 5:51 PM, p2ee list for developers
<p2e...@li...> wrote:
> Reviewing your ideas for the inventory model, I have a doubt:
>
> When you explained the Inventory model and how a unique part is going to be
> the combination of: catalog+warehouse+account, What i think first is how to
> identify in the same warehouse from a storage point of view which parts
> belongs to one area (projects) and which parts belongs to other areas?

Well, that's a very interesting question. I see 3 points of view:
Catalog Management, Inventory Management and Warehouse Management. The
first is having a corporate catalog with technical specs, compatible
items, etc. The second deals with quantities costs and accounting of
Inventory and the third deals mostly with "where", the physical
distribution of things. Depending on the type of business, yo may have
more emphasis in one of the 3 aspects of materials management.

For this reason, I designed the model in order to be able to expand
this functionality with time, with minimal impact to the other aspects
of materials management. At the moment, the DB model is mostly
Inventory with just a bit of Warehouse management.

The model per-se does not force that an inventory part (catalog id +
warehouse id + inv account id) be tied to a different location as not
all businesses require this. But this condition could easily be forced
at the application level, in the workflow.

Remember that in p2ee, you should not have direct access to the data
model (a common mistake of many applications). I mean, the screens and
forms are always process-driven and not data driven (the fields on the
screen are not directly tied to the database model, in other words, a
particular screen does not necessarily reflect a particular database
record). This means that even if you have the same catalog part in the
same warehouse, with 5 different accounts, and in the same physical
location, you could never withdraw more than you have for that
account, because you don't see them. This is because in the model one
inventory item has a one to many relationship to warehouse locations
(very common in many systems).

On the other hand, from a warehouse management point of view, you
could determine in one particular bin how many parts belong to what.
Say you have 50 fuses, the system could you that 31 are for this
project and 19 are consumables. Of course, you could not determine
exactly which ones (unless you separate them in different physical
locations), but many companies don't care. Although, in reality,
project parts are effectively kept away from maintenance parts, for
example. So the answer is that _yes_ they _could_ be separated but the
DB model does not force it.

> If you are using inventory location are you going to have separate parts
> that belong to different areas?

Right now in the DB model, locations are derived from the inventory
parts. The location name is just plain text and for V1 I did not
expect to have more warehouse functionality than that. In the future,
the locations table could be changed to a connecting table between an
actual locations management functionality and the inventory parts. In
other words you could not make-up locations, but you would have to
chose from the pre-declared locations structure. This extension is
foreseen but not for V1.


The model allows for a part to be in one or more locations. Or

> You have other level of segregation of the material balances: lots,
> conditions?

Great question. Every single inventory reception transaction generates
a lot. This allows for each inventory part to have different costing
method (FIFO, LIFO or AVG), even if they are the same catalog item.
When you return parts, say parts you did not use in a work order, it
reverses to that specific lot. You could even force that lots have
separate physical locations but that is not forced at the DB level,
because in many scenarios, the lots will be used only for cost
accounting purposes. In other scenarios, the lots may be of high
importance especially for perishable articles.

>
> As I see on other inventory solutions, there is a commodity group which is
> associated to a resource code, one component of the glaccount, is this
> similar to your model???

Nop. The account is just for recording the transaction, and apart from
the costing method, the Inventory systems does not care much about GL.
So the is no logic between account components and the Inventory
functionality. Remember that in p2ee we want to keep each domain
completely separate from one another, so you could integrate any GL
system to the Inventory app and vice versa.

We currently have no plans for a GL application and we are planning to
offer integration to GNU Cash initially. What we have found in reality
that tight integration with GL in general is just intellectual
masturbation because in reality accounting as such is almost always
done by an external party (an external CPA). So pretending to have
such close ties between different ERP domains and GL is just simply
stupid, as the _real_ books hardly ever reflect the system books, and
making them match usually resorts to consolidation processes and
adjustments on either side. Again, making them match electronically is
just simply not very important and simply stupid.... this is one of
the major flaws I see in a system like Sql-Ledger and it's
derivatives.

Please check-out the project and open the inventory model in this directory:

p2ee/inventory/trunk/inventory/data/model/inventory.dia

You will need DIA which is avalable in almost all Linux/*bsd distros
as well as for Windows 32.

http://www.gnome.org/projects/dia/

Thanks for your participation, Ninoska! Just take a look at the actual
DB model and let's expand this discussion from a DB standpoint. I will
resume work on the virtual machine so many of you can simply download
and play with p2ee as-is. I'm sorry to have paused development for the
last 3 moths but the December deadline stressed me out and I got burnt
and needed a break from this project. Besides, it was getting pretty
lonely here, but your participation has sparked my comeback! Thanks!

Alex

>
> On Wed, Jan 6, 2010 at 2:42 PM, p2ee list for developers
> <p2e...@li...> wrote:
>>
>> Before initiating discussion I would like to expand a bit more on this:
>>
>> The general idea if you look at the model is that you have:
>>
>>

Re: [p2ee-devel] Material Requests - 102 - Explained

[p2ee l. f. d. <p2e...@li...>]

Reviewing your ideas for the inventory model, I have a doubt:

When you explained the Inventory model and how a unique part is going to be
the combination of: catalog+warehouse+account, What i think first is how to
identify in the same warehouse from a storage point of view which parts
belongs to one area (projects) and which parts belongs to other areas?
If you are using inventory location are you going to have separate parts
that belong to different areas?
You have other level of segregation of the material balances: lots,
conditions?

As I see on other inventory solutions, there is a commodity group which is
associated to a resource code, one component of the glaccount, is this
similar to your model???

On Wed, Jan 6, 2010 at 2:42 PM, p2ee list for developers <
p2e...@li...> wrote:

> Before initiating discussion I would like to expand a bit more on this:
>
> The general idea if you look at the model is that you have:
>
> 1) A Corporate Catalog. This is quite common, regardless if all
> warehouses carry all parts of not, a corporate catalog is usually a
> separate piece of information. Parts specifications are managed at the
> catalog level as well as part number equivalencies and descriptions.
>
> 2) Warehouses. A company may have several warehouse locations. A
> warehouse represents a physical location where material is stored. It
> has a description, address, contact person, telephone, etc.
>
> 3) Inventory. The combination of a Warehouse location and a catalog
> item will render an Inventory item. In other words a catalog item in a
> specific location. Here is the tricky part... there can be multiple
> Inventories of the same part in a single warehouse. This is because
> the Inventory in p2ee is actually warehouse+catalog+account. So you
> may have the same catalog part in different inventories at the same
> warehouse. This allows separation of raw materials from spare parts
> and project parts, even though they may have the same catalog
> number!!!
>
> 4) Inventory Location. For each inventory, you may have multiple
> physical locations within the warehouse. This could even be tied to
> lots. This is because in p2ee every time material enters a warehouse
> it generates a lot (this allows for easy FIFO and LIFO cost methods,
> and for tracking raw material lots as well.).
>
>
> What we are proposing is that direct issue materials create an
> inventory entry for the cost center's account (although this inventory
> might exist already). This would require a slight change in the user
> interface as the user would have to select the warehouse, then the
> inventory (the account) and then the operation. I don't see any
> problem with this but perhaps some potential users might. Please
> advise if so.
>
> Best,
> Alejandro Imass
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> p2ee-devel mailing list
> p2e...@li...
> https://lists.sourceforge.net/lists/listinfo/p2ee-devel
>

[p2ee-devel] Material Requests - 102 - Explained

[p2ee l. f. d. <p2e...@li...>]

Before initiating discussion I would like to expand a bit more on this:

The general idea if you look at the model is that you have:

1) A Corporate Catalog. This is quite common, regardless if all
warehouses carry all parts of not, a corporate catalog is usually a
separate piece of information. Parts specifications are managed at the
catalog level as well as part number equivalencies and descriptions.

2) Warehouses. A company may have several warehouse locations. A
warehouse represents a physical location where material is stored. It
has a description, address, contact person, telephone, etc.

3) Inventory. The combination of a Warehouse location and a catalog
item will render an Inventory item. In other words a catalog item in a
specific location. Here is the tricky part... there can be multiple
Inventories of the same part in a single warehouse. This is because
the Inventory in p2ee is actually warehouse+catalog+account. So you
may have the same catalog part in different inventories at the same
warehouse. This allows separation of raw materials from spare parts
and project parts, even though they may have the same catalog
number!!!

4) Inventory Location. For each inventory, you may have multiple
physical locations within the warehouse. This could even be tied to
lots. This is because in p2ee every time material enters a warehouse
it generates a lot (this allows for easy FIFO and LIFO cost methods,
and for tracking raw material lots as well.).


What we are proposing is that direct issue materials create an
inventory entry for the cost center's account (although this inventory
might exist already). This would require a slight change in the user
interface as the user would have to select the warehouse, then the
inventory (the account) and then the operation. I don't see any
problem with this but perhaps some potential users might. Please
advise if so.

Best,
Alejandro Imass

[p2ee-devel] Material Requests - 102

[p2ee l. f. d. <p2e...@li...>]

Hi all,

I am sorry that no one responded to "Material Requests - 101", I am
hoping and confident this will change with this thread ;-)

During the holiday I refined this requirement and data model and here
is the new proposal:


Case 1: Direct Issue Material Request to Purchasing
-----------------------------------------------------------------------------
A person (a cost center) can place a "direct issue" order directly to
purchasing and the material will be delivered at the requestor's
location, not having anything to do with inventory. This functionality
will be covered and discussed in the purchasing application.
Nevertheless it shows that Material Requests are in both the
functional domain of Purchasing as well as the functional domain of
Inventory. (this contradicts MR 101 in the sense that it was proposed
that MR be a functional domain of it's own).

So, from a user's perspective, she will order parts directly through
purchasing PR and receive the parts directly at her location. Users
that want direct-issue parts but tha want them at their inventory
location,l will generate a direct-issue MR to their inventory location
- see below.

You may ask: who would want to order direct material through
inventory? - projects for example. If you are constructing a new
well-pad (Oil&Gas) you will use many of the materials you already have
in you catalog. These material nonetheless should not be posted as
regular MRs because they will throw-off you inventory statistics
(average use, ROP, lead time etc.), and also, these parts should be
affecting another inventory account (not your normal inventory
account).

Case 2: Direct Issue Material Requests Through Inventory
----------------------------------------------------------------------------------
Another scenario are MRs that are placed as "direct issue" to the cost
center but delivered through the inventory location. This second case,
the MR is placed to the warehouse, not affecting inventory levels
(reservation and ordering) and/or costs. A PR is generated from the
inventory system to purchasing (regardless of current stock). When the
part arrives, it is received by the inventory location but charged
directly to the requesting cost center.

Here is how it's gonna work technically:

For those who have seen the latest model, each part has an accounting
configuration: debit acc, credit acc and cog acc. Even if p2ee
inventory is disconnected from a GL system, there is an account
interface table where these accounts can be mapped to the GL's
accounting system. Anyway, my idea is to ask for the cost center's
account and create new inventory records for this direct-issue request
(if they don't exist). So now the unique index on the inventory table
is catalog_id+inventory_id+account_id !

I think this be awesome because it will allow for separation of
inventory functions by inventory accounts! (i.e. show me all requests
for account x-x-x-x or in other words process all requests for project
so and so).


Case 3: Normal Material Requests Through Inventory
-----------------------------------------------------------------------------
This is probably the most normal scenario. The MR is placed to the
warehouse, it increment the reservation and the part is dispatched to
the requesting cost centered. Of course, I am omitting the
replenishment details, but just wanted to illustrate this function.

Important Notes
------------------------
It is important to note that an MR as stated above is a generalized
version of actual demanders such as Work Orders, Production Orders,
Sales Orders and such. These applications when they are eventually
built, will generate MRs that reference to the originating doc (the
WO, PO, SO, etc.), but in the end it's just a request from the
Inventory's point of view. Please look at the Use Cases and Class
Collaboration diagram at:
p2ee/inventory/trunk/inventory/data/model/inventory.dia _before_ you
engage on model discussions here!


Thanks,
Alejandro Imass

[p2ee-devel] Happy New Year!!! - Welcome Ninoska !

[Alejandro I. <ai...@p2...>]

Hi all,

I hope you have had happy holidays and hope the best for you all this
new year of 2010.

At p2ee we are continuing to attract talent from friends all-over.
This time I would like to welcome Ninoska Acosta to the list. Ninoska
has a few dozen EAM projects under her sleeve so I am sure she will be
a great asset to our team.

So far I have been the only active participant on the list (although
there are more than 20 people on the list! - all lurkers) so I hope
that Ninoska will share some of her valuable knowledge with us.

Best,
Alejandro Imass

[p2ee-devel] Your opinion matters! - Please participate in the functional discussions!

[Alejandro I. <ai...@p2...>]

Hi folks,

Now is the time to help us defne the needs of p2ee inventory!
There are new people on the list every day but remain lurking terribly
silent :-(

I have sent 3 important functional discussions:

1) Material Classifications 101
2) Material Conditions, Rotables and Serialized Items 101
3) Material Requests - 101

And there are some more to come....

Your valuable input right now is very important to us before we stamp
the final model for v0.01
We __will__ go Beta by year eand so if you want to see your desired
functionallity in this release please speak up now!!!

The Virtual Box Development Enviroment will be delayed for early next
week. We want to set-up the LDAP stuff and leave it working so we
don't have to release a new VM any time soon. All comon data and many
other things will be stored in LDAP -the right way- even users and
their roles ;-)

Cheers,
Alejandro Imass

[p2ee-devel] Material Classifications 101

[Alejandro I. <ai...@p2...>]

At the catalog level we currently have Class and Sub-Class, a simple 2
level hierarchy. Most companies won't need more levels than these, but
we could define a formal hierarchy model for this. Honestly if anyone
thinks that 2 levels may not be enough for a particular industry
please advise!!!

When Hernán first looked at the model his first question was: but
where are the attributes for each class and sub-class. The answer is
that we are using PostgreSql and _only_ Pg. This ORDBMS allows for
active inheritance, so the idea is that customers may derive their own
classification tables from the p2ee ones. This is *MUCH* better than
supporting "dynamic" attribute models which wind up with humongous
data tables and complex querying, and of course is *WAY* better than
having hundreds of un-used columns (I have seen this for real on some
ERPs).

Best,
Alejandro Imass

[p2ee-devel] Material Conditions, Rotables and Serialized Items - 101

[Alejandro I. <ai...@p2...>]

SORRY, FORGOT THE NUMBER PLEASE RESPOND TO THIS THREAD NOT THE PREVIOUS ONE!!!

Well, this should be a rich thread.

Mainly used in the Oil, Aeronautical and Asset Management in general,
the idea is that there are pieces of inventory which can be in
different conditions such as NEW, REFURBISHED, GOOD, FAIR, or
whatever. The conditions may be (and are usually) tied to a cost,
meaning that the same material in different conditions cost
differently. This is the SAME inventory item code but with different
conditions. I have seen this modeled in many ways, such as ITEMCODE-XX
where XX is the condition, or in other Warehouse management tools it
may be related to the bin location (i.e. items in bin X are of
condition YY).

To me, the best and most generic way of handling this is by handling
serialized parts (already laid out for p2ee inventory 0.1). The
problem with this approach is that every single item that needs to
manage conditions needs to be serialized, but such is life.

So here is my proposal:

Items will have three boolean bits (at the catalog level):
- serialized
- rotable
- condition

Serialized can be alone or with condition OR rotable, but rotable and
condition are mutually exclusive. Selecting rotable or condition will
automatically select serialized.

Rotables
--------------
The idea here is that a rotable is a piece of equipment that will
carry it's own repair costs and they are received and dispatched from
inventory at cost Zero. The Asset Management application will be
responsible of tracking the costs that are done on the rotables.

Serialized
---------------
Serialized-only parts will not have conditions (duh!) they are mainly
used to track the items for regulatory purposes (Aviation, for
example). In fact, in industries such as Aviation the serial number
changes when the part is refurbished, so we need to support changing
of the serial number.

Conditions
---------------
Serialized items with conditions will allow to change the condition of
the item and in turn it will change the cost, instead of handling
specific prices for conditions I think most, if not all customers,
will be happy to be able to define a percentage of the NEW price
associated with the condition.


The catch here is that to handle conditions items need to be
serialized. The system, will assign a unique number when receiving
these parts. For example when the user receives 50 parts from the OEM,
a 50 line list will be displayed with the automated system-assigned
numbers. The user could very well just click continue and then
print-out heavy-duty bar code labels and just stick them to the
serialized items, or will print-out the serial numbers to be manually
etched to the parts. It will also allow the operator to key-in the
actual serial numbers from the parts, so no labels or reports need to
be printed. That is the vision here: a guy receives 30 laptops and the
system sees that these are serialized items with conditions (a
computer store), the system will the automatically display 30 lines so
the user can key in or scan the bar codes into the reception
transaction. From then on, the user must specify which serial numbers
are coming or going from inventory (same functionality on dispatch,
returns, etc.).

[p2ee-devel] Material Conditions, Serialized Items and Rotable

[Alejandro I. <ai...@p2...>]

Well, this should be a rich thread.

Mainly used in the Oil, Aeronautical and Asset Management in general,
the idea is that there are pieces of inventory which can be in
different conditions such as NEW, REFURBISHED, GOOD, FAIR, or
whatever. The conditions may be (and are usually) tied to a cost,
meaning that the same material in different conditions cost
differently. This is the SAME inventory item code but with different
conditions. I have seen this modeled in many ways, such as ITEMCODE-XX
where XX is the condition, or in other Warehouse management tools it
may be related to the bin location (i.e. items in bin X are of
condition YY).

To me, the best and most generic way of handling this is by handling
serialized parts (already laid out for p2ee inventory 0.1). The
problem with this approach is that every single item that needs to
manage conditions needs to be serialized, but such is life.

So here is my proposal:

Items will have three boolean bits (at the catalog level):
- serialized
- rotable
- condition

Serialized can be alone or with condition OR rotable, but rotable and
condition are mutually exclusive. Selecting rotable or condition will
automatically select serialized.

Rotables
--------------
The idea here is that a rotable is a piece of equipment that will
carry it's own repair costs and they are received and dispatched from
inventory at cost Zero. The Asset Management application will be
responsible of tracking the costs that are done on the rotables.

Serialized
---------------
Serialized-only parts will not have conditions (duh!) they are mainly
used to track the items for regulatory purposes (Aviation, for
example). In fact, in industries such as Aviation the serial number
changes when the part is refurbished, so we need to support changing
of the serial number.

Conditions
---------------
Serialized items with conditions will allow to change the condition of
the item and in turn it will change the cost, instead of handling
specific prices for conditions I think most, if not all customers,
will be happy to be able to define a percentage of the NEW price
associated with the condition.


The catch here is that to handle conditions items need to be
serialized. The system, will assign a unique number when receiving
these parts. For example when the user receives 50 parts from the OEM,
a 50 line list will be displayed with the automated system-assigned
numbers. The user could very well just click continue and then
print-out heavy-duty bar code labels and just stick them to the
serialized items, or will print-out the serial numbers to be manually
etched to the parts. It will also allow the operator to key-in the
actual serial numbers from the parts, so no labels or reports need to
be printed. That is the vision here: a guy receives 30 laptops and the
system sees that these are serialized items with conditions (a
computer store), the system will the automatically display 30 lines so
the user can key in or scan the bar codes into the reception
transaction. From then on, the user must specify which serial numbers
are coming or going from inventory (same functionality on dispatch,
returns, etc.).

[p2ee-devel] Material Requests - 101

[Alejandro I. <ai...@p2...>]

Hi all, and thanks for your previous comments.

As promised, here is the first thread Hernán and I discussed. I will
number these threads so they will be easy to spot in a mail archive
indexer.


Material Requests are probably a function in their own domain. This
means that they don't belong to purchasing nor inventory per se, so
they necessarily have to separated into their own functional domain.

Case 1: Direct Issue Material Request to Purchasing
-----------------------------------------------------------------------------
A person (a cost center) can place a "direct issue" order directly to
purchasing and the material will be delivered at the requestor's
location, not having anything to do with inventory. This functionality
will be covered and discussed in the purchasing application.
Nevertheless it shows that Material Requests are in a functional
domain of their own, see below.

Case 2: Direct Issue Material Requests Through Inventory
----------------------------------------------------------------------------------
Another scenario are MRs that are placed as "direct issue" to the cost
center but delivered through the inventory location. This second case,
the MR is placed to the warehouse, not affecting inventory levels
(reservation and ordering) and/or costs, an the PR is sent from the
inventory system to purchasing. When the part arrives, it is received
by the inventory location but charged directly to the requesting cost
center. The costs are probably handled through a bridge account for
these types of transactions. This is not defined to the exact detail,
but you get the idea.

Case 3: Normal Material Requests Through Inventory
-----------------------------------------------------------------------------
This is probably the most normal scenario. The MR is placed to the
warehouse, it increment the reservation and the part is dispatched to
the requesting cost centered. Of course, I am omitting the
replenishment details, but just wanted to illustrate this function.

Important Notes
------------------------
It is important to note that an MR as stated above is a generalized
version of actual demanders such as Work Orders, Production Orders,
Sales Orders and such. These applications when they are eventually
built, will generate MRs that reference to the originating doc (the
WO, PO, SO, etc.), but in the end it's just a request from the
Inventory's point of view. Please look at the Use Cases and Class
Collaboration diagram at:
p2ee/inventory/trunk/inventory/data/model/inventory.dia _before_ you
engage on model discussions here!


Conclusion:

- A Material Request Application is needed separate from purchasing or
inventory. This applications will probably be used by disparate
material not directly associated to Work, Production or Sales, as
these should be handled by the normal MRP of the inventory system.

- p2ee Inventory will support case 2 and 3 scenarios, that is, will
support scenario 2 which was the actual discussion between Hernán and
myself, as scenario 3 had to be obviously supported.

Questions for discussion:

- Does anyone else see other scenarios or problems with the proposed
functionality of release 0.1?
- Would anyone like to add any comments or ideas regarding material requests?

Thanks,
Alejandro Imass

Re: [p2ee-devel] Welcome Hernán Rincón! - Inventory Model Discussion 101

[Jeff Z. <je...@vp...>]

Welcome Alberto and Hernán!  I'm just sort of a cheerleader for the project
but I congratulate you on your progress.  Alejandro - if you can think of
something useful for me to do, perhaps on the front end or AJAX interaction,
let me know.

-- 
Jeff

On Mon, Dec 7, 2009 at 4:53 AM, Alejandro Imass <ai...@p2...> wrote:

> Hi all!
>
> I'd like to welcome Hernán Rincón to the list and to the project.
>
> Hernan is an expert in ERP systems, Unix and Perl. We worked together
> in a couple of projects for very large operators such as Woodgroup,
> BP, and Occidental to name a few. Especially regarding the strangest
> inventory scenarios for the large oil companies, for example we
> homologue BP's and Woddgroup's catalog with (at the time) leading-edge
> catalog management tools such as Struxure, focused at Reliability
> Centered Maintenance.
>
> Now that the Inventory app is taking it's final shape, Hernán will
> work with me to finish the first three apps and we will do our best to
> sustain the model discussions here on the list.
>
> Our first discussion (via chat) was regarding Material Requests,
> Costing Models, Multiple Currencies, Transaction Types, and Material
> Classifications and Conditions, to name a few. I will create
> individual threads so anyone in the list can give us their 2 cents.
> The idea is to fix the model for Inventory 0.1 this week, and finish
> the functionallity hopefully before th 24th. After that we will
> provide verya basic Purchasing and Sales Apps, and p2ee will be ready
> for SMB use right away. As you may have seen from our architecture, we
> can handle very small companies, but the ultimate goal is actually
> *VERY* large scale deployments such as those provided by Google Apps.
>
> Best,
> Alejandro Imass
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> p2ee-devel mailing list
> p2e...@li...
> https://lists.sourceforge.net/lists/listinfo/p2ee-devel
>

[p2ee-devel] Welcome Hernán Rincón! - Inventory Model Discussion 101

[Alejandro I. <ai...@p2...>]

Hi all!

I'd like to welcome Hernán Rincón to the list and to the project.

Hernan is an expert in ERP systems, Unix and Perl. We worked together
in a couple of projects for very large operators such as Woodgroup,
BP, and Occidental to name a few. Especially regarding the strangest
inventory scenarios for the large oil companies, for example we
homologue BP's and Woddgroup's catalog with (at the time) leading-edge
catalog management tools such as Struxure, focused at Reliability
Centered Maintenance.

Now that the Inventory app is taking it's final shape, Hernán will
work with me to finish the first three apps and we will do our best to
sustain the model discussions here on the list.

Our first discussion (via chat) was regarding Material Requests,
Costing Models, Multiple Currencies, Transaction Types, and Material
Classifications and Conditions, to name a few. I will create
individual threads so anyone in the list can give us their 2 cents.
The idea is to fix the model for Inventory 0.1 this week, and finish
the functionallity hopefully before th 24th. After that we will
provide verya basic Purchasing and Sales Apps, and p2ee will be ready
for SMB use right away. As you may have seen from our architecture, we
can handle very small companies, but the ultimate goal is actually
*VERY* large scale deployments such as those provided by Google Apps.

Best,
Alejandro Imass

Re: [p2ee-devel] Welcome Alberto Mijares - p2ee Virtual Box is on the Way!

[Alberto M. <ami...@mc...>]

On Mon, Dec 7, 2009 at 5:34 AM, Alejandro Imass <ai...@p2...> wrote:
> Hi all!
>
> I'd like to welcome Alberto Mijares to the list and to the project.
>
> Alberto is an expert in *NIX sysadmin and he also a fine coder in that
> area. Alberto has helped me to create a Virtual Box VM that you will
> be able to download and run - easy!.
> It will include the complete development environment and tools so you
> can develop directly on the VM, or just run the desired software and
> use it directly as such from the VM.
>
[...]
> THANK YOU ALBERTO FOR MAKING THIS HAPPEN!


I'ts my pleasure to be part of such a great project (SAP, watch your back ;-)

I hope to be useful here.

Best regards,


Alberto Mijares