Notes on OpenPSA ...

1 2 next

Johan Bernhardsson

Notes on OpenPSA ...
Sun June 21 2009 15:33:38 UTC

Notes on OpenPSA.

Some notes on OpenPSA collected from conversations with bergie and flack.

Projects: - On creation of a project a project number should be created much like invoice numbers. This will ease registration of incoming invoices and expences. - The id should be shown everywhere to easy tracking of the project. A project name is handy but not to everyone. (For example if you have three new server sales projects at the same time.) - Tasks should be linked to a customer aswell. All projects should be linked to a customer. Regardless if we have an agreement from sales or not.

Sales: - When deliverables in a sale should be grouped together. When a sale is accepted by a customer, that sale should be transformed to a project with a project id. So when we invoice we will only have one invoice regardless on how many deliverables we have. And we should be able to select only some deliverables for one sale. (The client takes the server and installation but not the five workstations for example.) - Next event for a sale should be a task or a calendar item. Not only a task.

Invoices: - We should be able to handle incoming invoices. They should be linked to a project. They should be treaded as the others but a field that shows the supplier instead of a customer. - One supplier invoice can be linked to many different projects. (1 server for one client. 1 workstation for another and so on. This part will be tricky!!.) - Can we export this a sie (www.sie.se i think this is only a swedish format) or xbrl (a free and open standard www.xbrl.org this would be the most logical choice) This would help bookkeeping alot. Supplier invoices should be scanned and imported in some way. Batch mode or single mode. Most probably using pdf's. This would make projects management easier. Instant access to invoices linked to a project.
- One view would give a list of unhandled invoices with search fields to link them to projects based on id's or names. And a field to input the amount that that invoice should load the project. You should be able to enter several projects with amounts.

Expenses: - Hour reports should contain milages, so that we can keep track on that cost aswell. - A definition on milages costs should be made somewhere aswell. - A meeting in the calendar can also be an expense. The list of tasks when creating a report should only display open or not started tasks, not closed.

Directmarketing: - Responce from a campaign should/can this be linked to a sales project. So that reports can contain such information aswell?

Community/DBE: We should provide a DBE like functionality. Workflow should be able to work between different OpenPSA systems. A first step should be to query other systems for competence and send tasks between systems. This will probably be after we have fixed the other stuff :)
- Reply
Johan Bernhardsson

Re: Notes on OpenPSA ...
Sun June 21 2009 15:36:33 UTC

That formating got screwed up some :) Ill post a new one later on tonight ...
- Reply
Johan Bernhardsson

Re: Notes on OpenPSA ...
Sun June 21 2009 17:23:44 UTC

Contacts: - Organization should contain information about payment terms for that customer and credit status.
- Reply
Henri Bergius

Re: Notes on OpenPSA ...
Mon June 22 2009 07:36:35 UTC
Couple of additional things:

Contracts
- Management of contracts (validity period, terms, customers) would be useful, and with scanned-in PDFs remove some necessary paper archival
Meeting notes
- At least in our company we need to easily store and retrieve notes from various meetings. Originally n.n.wiki with "related to" was used for this, but I doubt it is optimal
/Henri
- Reply
Andreas Flack

Re: [midgard-user] Notes on OpenPSA ...
Mon June 22 2009 08:40:06 UTC
Johan Bernhardsson schrieb:
> Notes on OpenPSA.
> =================
> Some notes on OpenPSA collected from conversations with bergie and flack.
>
> **Projects:**
> - On creation of a project a project number should be created much like invoice numbers. This will ease registration of incoming invoices and expences.
> - The id should be shown everywhere to easy tracking of the project. A project name is handy but not to everyone. (For example if you have three new server sales projects at the same time.)
> - Tasks should be linked to a customer aswell.
> All projects should be linked to a customer. Regardless if we have an agreement from sales or not.

There is already a mandatory customer field when you create a project,
but from a database point of view, this is not very elegant, since it
introduces redundancy. F.x. if a project is linked to a salesproject,
you'd need to make sure that the salesproject customer and the project
customer match on each update.

Salesprojects also have this autogenerated project number you mention,
so I'm wondering if it wouldn't be better to merge salesproject and
project into one database table. Or at least to take out the
rendundancies between the two.

>
> **Sales:**
> - When deliverables in a sale should be grouped together. When a sale is accepted by a customer, that sale should be transformed to a project with a project id. So when we invoice we will only have one invoice regardless on how many deliverables we have. And we should be able to select only some deliverables for one sale. (The client takes the server and installation but not the five workstations for example.)
> - Next event for a sale should be a task or a calendar item. Not only a task.
>

Currently the logic is that if one deliverable of a salesproject gets
ordered, a project with a name correspondig to the salesproject is
created and a task with a name corresponding to the deliverable. In
o.o.invoices, there is a handler (/projects/) that allows you to create
an invoice for multiple (closed) tasks. All that would have to be added
would be to create a relatedto to the respective deliverable on invoice
creation and this would be implemented

> **Invoices:**
> - We should be able to handle incoming invoices. They should be linked to a project. They should be treaded as the others but a field that shows the supplier instead of a customer.
> - One supplier invoice can be linked to many different projects. (1 server for one client. 1 workstation for another and so on. This part will be tricky!!.)
> - Can we export this a sie (www.sie.se i think this is only a swedish format) or xbrl (a free and open standard www.xbrl.org this would be the most logical choice) This would help bookkeeping alot.
> Supplier invoices should be scanned and imported in some way. Batch mode or single mode. Most probably using pdf's. This would make projects management easier. Instant access to invoices linked to a project.
> - One view would give a list of unhandled invoices with search fields to link them to projects based on id's or names. And a field to input the amount that that invoice should load the project. You should be able to enter several projects with amounts.
>

> **Expenses:**
> - Hour reports should contain milages, so that we can keep track on that cost aswell.
> - A definition on milages costs should be made somewhere aswell.
> - A meeting in the calendar can also be an expense.
> The list of tasks when creating a report should only display open or not started tasks, not closed.
>
> **Directmarketing:**
> - Responce from a campaign should/can this be linked to a sales project. So that reports can contain such information aswell?
>
>
> **Community/DBE:**
> We should provide a DBE like functionality. Workflow should be able to work between different OpenPSA systems. A first step should be to query other systems for competence and send tasks between systems. This will probably be after we have fixed the other stuff :)
> _______________________________________________
> user mailing list
> user@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/user
_______________________________________________
user mailing list
user@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/user
- Reply
Johan Bernhardsson

Re: [midgard-user] Notes on OpenPSA ...
Mon June 22 2009 08:55:05 UTC
On Mon, 2009-06-22 at 09:27 +0200, Henri Bergius wrote:
> Couple of additional things:
>
> **Contracts**
>
> - Management of contracts (validity period, terms, customers) would be useful, and with scanned-in PDFs remove some necessary paper archival

Very useful.

> **Meeting notes**
>
> - At least in our company we need to easily store and retrieve notes from various meetings. Originally n.n.wiki with "related to" was used for this, but I doubt it is optimal

Construct a new component for notes ? Or a component where you can write
text documents thats gets stored in the right place of o.o.documents.
And a view for text/html documents inline.

We write meeting documents to. But those are stored as normal documents.

/johan

_______________________________________________
user mailing list
user@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/user
- Reply
Andreas Flack

Re: [midgard-user] Notes on OpenPSA ...
Mon June 22 2009 09:05:05 UTC
Johan Bernhardsson schrieb:
>
> On Mon, 2009-06-22 at 09:27 +0200, Henri Bergius wrote:
>> Couple of additional things:
>>
>> **Contracts**
>>
>> - Management of contracts (validity period, terms, customers) would be useful, and with scanned-in PDFs remove some necessary paper archival
>
> Very useful.
>
>
>> **Meeting notes**
>>
>> - At least in our company we need to easily store and retrieve notes from various meetings. Originally n.n.wiki with "related to" was used for this, but I doubt it is optimal
>
> Construct a new component for notes ? Or a component where you can write
> text documents thats gets stored in the right place of o.o.documents.
> And a view for text/html documents inline.

If you want to take the o.o.documents route, maybe it would be enough
just to modify the DM2 schema a little: If you change the abstract field
to use tinymce or markdown (and change its name to "notes"), you could
simply write your notes there.

Also I'm thinking about removing the limitation of one file per document
object. That way you could add different formats (f.x. OO editable
document and PDF rendering) or all the PPTs used in one meeting (with
the accompanying notes in the abstract field). The only issue with that
is that the backup_version mechanism would have to be changed

>
> We write meeting documents to. But those are stored as normal documents.
>
> /johan
>
>
> _______________________________________________
> user mailing list
> user@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/user
_______________________________________________
user mailing list
user@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/user
- Reply
Johan Bernhardsson

Re: [midgard-user] Notes on OpenPSA ...
Mon June 22 2009 09:05:08 UTC
On Mon, 2009-06-22 at 10:26 +0200, Andreas Flack wrote:
>
> Johan Bernhardsson schrieb:
> > Notes on OpenPSA.
> > =================
> > Some notes on OpenPSA collected from conversations with bergie and flack.
> >
> > **Projects:**
> > - On creation of a project a project number should be created much like invoice numbers. This will ease registration of incoming invoices and expences.
> > - The id should be shown everywhere to easy tracking of the project. A project name is handy but not to everyone. (For example if you have three new server sales projects at the same time.)
> > - Tasks should be linked to a customer aswell.
> > All projects should be linked to a customer. Regardless if we have an agreement from sales or not.
>
> There is already a mandatory customer field when you create a project,
> but from a database point of view, this is not very elegant, since it
> introduces redundancy. F.x. if a project is linked to a salesproject,
> you'd need to make sure that the salesproject customer and the project
> customer match on each update.
>
> Salesprojects also have this autogenerated project number you mention,
> so I'm wondering if it wouldn't be better to merge salesproject and
> project into one database table. Or at least to take out the
> rendundancies between the two.

Yes there seem to be alot of unneeded redundancies between them. In the
workflow scenario that im used to. We create the project number when the
order is made. So that we can mark all orders we make from suppliers
with that number.

Than number should be connected to the invoice in some way.

> >
> > **Sales:**
> > - When deliverables in a sale should be grouped together. When a sale is accepted by a customer, that sale should be transformed to a project with a project id. So when we invoice we will only have one invoice regardless on how many deliverables we have. And we should be able to select only some deliverables for one sale. (The client takes the server and installation but not the five workstations for example.)
> > - Next event for a sale should be a task or a calendar item. Not only a task.
> >
>
> Currently the logic is that if one deliverable of a salesproject gets
> ordered, a project with a name correspondig to the salesproject is
> created and a task with a name corresponding to the deliverable. In
> o.o.invoices, there is a handler (/projects/) that allows you to create
> an invoice for multiple (closed) tasks. All that would have to be added
> would be to create a relatedto to the respective deliverable on invoice
> creation and this would be implemented

If its the simple way to go :) It would ease workflow if we could
arrange it. All other software always makes you go an extra step. If we
could avoid this, it would be pretty good.

> > **Invoices:**
> > - We should be able to handle incoming invoices. They should be linked to a project. They should be treaded as the others but a field that shows the supplier instead of a customer.
> > - One supplier invoice can be linked to many different projects. (1 server for one client. 1 workstation for another and so on. This part will be tricky!!.)
> > - Can we export this a sie (www.sie.se i think this is only a swedish format) or xbrl (a free and open standard www.xbrl.org this would be the most logical choice) This would help bookkeeping alot.
> > Supplier invoices should be scanned and imported in some way. Batch mode or single mode. Most probably using pdf's. This would make projects management easier. Instant access to invoices linked to a project.
> > - One view would give a list of unhandled invoices with search fields to link them to projects based on id's or names. And a field to input the amount that that invoice should load the project. You should be able to enter several projects with amounts.
> >
>
> > **Expenses:**
> > - Hour reports should contain milages, so that we can keep track on that cost aswell.
> > - A definition on milages costs should be made somewhere aswell.
> > - A meeting in the calendar can also be an expense.
> > The list of tasks when creating a report should only display open or not started tasks, not closed.
> >
> > **Directmarketing:**
> > - Responce from a campaign should/can this be linked to a sales project. So that reports can contain such information aswell?
> >
> >
> > **Community/DBE:**
> > We should provide a DBE like functionality. Workflow should be able to work between different OpenPSA systems. A first step should be to query other systems for competence and send tasks between systems. This will probably be after we have fixed the other stuff :)
> > _______________________________________________

_______________________________________________
user mailing list
user@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/user
- Reply
Henri Bergius

Re: [midgard-user] Notes on OpenPSA ...
Mon June 22 2009 09:20:05 UTC
Hi,

On Mon, Jun 22, 2009 at 11:26 AM, Andreas
Flack<flack@contentcontrol-berlin.de> wrote:
> Salesprojects also have this autogenerated project number you mention,
> so I'm wondering if it wouldn't be better to merge salesproject and
> project into one database table. Or at least to take out the
> rendundancies between the two.

If you take this a bit further, you could then do some "preparatory
scheduling" of projects before the sales are closed. This would help
with estimating resource utilization and so forth.

Then just change the project and task status when the project is sold.

/Henri

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius@gmail.com
Microblog: http://www.qaiku.com/home/bergie/
_______________________________________________
user mailing list
user@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/user
- Reply
Johan Bernhardsson

Re: [midgard-user] Notes on OpenPSA ...
Mon June 22 2009 16:30:04 UTC
And for some stuff ive been reading up on today ....

Some way to handle workstreaming in OpenPSA. While streaming to quaiku
is nice. But thats not what everyone wants ...

Can also be done by reading a qaiku's rss feed for a channel ,,,

On Mon, 2009-06-22 at 12:03 +0300, Henri Bergius wrote:
> Hi,
>
> On Mon, Jun 22, 2009 at 11:26 AM, Andreas
> Flack<flack@contentcontrol-berlin.de> wrote:
> > Salesprojects also have this autogenerated project number you mention,
> > so I'm wondering if it wouldn't be better to merge salesproject and
> > project into one database table. Or at least to take out the
> > rendundancies between the two.
>
> If you take this a bit further, you could then do some "preparatory
> scheduling" of projects before the sales are closed. This would help
> with estimating resource utilization and so forth.
>
> Then just change the project and task status when the project is sold.
>
> /Henri
>

_______________________________________________
user mailing list
user@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/user
- Reply

1 2 next

Notes on OpenPSA ...

Notes on OpenPSA.