What's missing?

[ngegw]

projectERP is fairly capable at this point, so I’m curious as to
what’s missing before pERP will work for you in your country / region.
I’m mostly interested in national restrictions, rather than industry
specific things, so I can try and remove any remaining barriers.

Nathan

---

Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

---

Perp-developers mailing list
Perp-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perp-developers

[MicheleT]

There are some things I forgot to mention about VATIN and other fiscal codes on invoices and on other fiscal documents:
1) we need those two codes for our company too, not only for clients and suppliers.
2) we must distinguish if a client/supplier is a physical person or a company, and consequently consider private or company Addressbook infos (i.e. address, phone numbers, etc.).
3) of a physical person we need to know the gender, birth date and birth location (these data are necessary to check validity of fiscal codes.)
4) another great feature, mainly for eGW but that would be very important for pERP too, could be the option to link a custom defined validation procedure/function to any custom field. If this was possible one could write, for example, functions to check formal validity of those fiscal codes or to post them to a web site/service (see VIES http://www1.agenziaentrate.it/servizi/vies/vies.htm) that can control if they exist or not, etc.

By the way, considering that we already have those codes (for our company, clients and suppliers) in eGW Addressbook custom fields, it would be very nice if pERP could recover or link to those data.

Michele

[ngegw]

Thank you for your response.

There are some things I forgot to mention about VATIN and other fiscal codes
on invoices and on other fiscal documents:

1. we need those two codes for our company too, not only for clients and
   suppliers.

Easy enough to do. They should probably go in Admin -> pERP -> Site
config. Is that correct?
Or, if every company in Italy has these and that’s where everyone
already puts them, would a better place be as custom fields in the
addressbook? This would include your company’s own address record
easily.

2. we must distinguish if a client/supplier is a physical person or a
   company, and consequently consider private or company Addressbook infos
   (i.e. address, phone numbers, etc.).

Where would this consideration take place?
It would be fairly easy to change the invoice report, for example, to
use the company address if present, or the private address if company
is missing.

3. of a physical person we need to know the gender, birth date and birth
   location (these data are necessary to check validity of fiscal codes.)

Wow. Under some circumstances in Canada, you can’t even ask those
questions, either by politeness or law, depending on the situation.
(Gender is usually pretty obvious though…)

4. another great feature, mainly for eGW but that would be very
   important for pERP too, could be the option to link a custom defined
   validation procedure/function to any custom field.

That would be a nice feature, but only applies to the text type.
It could probably be implemented so you could provide your regex or
validation callback function as an option.

By the way, considering that we already have those codes (for our company,
clients and suppliers) in eGW Addressbook custom fields, it would be very
nice if pERP could recover or link to those data.

It can if the information is in the client’s billing address. It
doesn’t do anything in particular with it, but it is accessible.
How it gets accessed depends on how you want to use it.
For example, to add a client’s VATIN number from the addressbook
custom field ‘vatin’ to the invoice report, you need to add this to
the invoice report template:
[invoice.bill.#vatin;noerr;]
To display the addressbook’s custom fields in the client list would be
a little more complicated.

Nathan

---

Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

---

Perp-developers mailing list
Perp-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perp-developers

[MicheleT]

1. we need those two codes for our company too, not only for clients and
   suppliers.

Easy enough to do. They should probably go in Admin -> pERP -> Site
config. Is that correct?

I think so, but…

Or, if every company in Italy has these and that’s where everyone
already puts them, would a better place be as custom fields in the
addressbook? This would include your company’s own address record
easily.

… I guess this one could be an easier and more homogeneous way. This is exactly what we do in eGW’s addressbook. And yes, every Italian company has a VAT code (this is true for most European countries too); every Italian physical person or company has a fiscal code.

2. we must distinguish if a client/supplier is a physical person or a
   company, and consequently consider private or company Addressbook infos
   (i.e. address, phone numbers, etc.).

Where would this consideration take place?
It would be fairly easy to change the invoice report, for example, to
use the company address if present, or the private address if company
is missing.

It would be better if that report could made that choise looking at some addressbok categories (i.e. Company and Private). Consider that in addressbook one can create a record for a company (that includes only the company address) and another one for an employee of that company (that includes company and private address). But it’s not only a matter of reports: in a client/supplier form or list we need to see the correct address.

3. of a physical person we need to know the gender, birth date and birth
   location (these data are necessary to check validity of fiscal codes.)

Wow. Under some circumstances in Canada, you can’t even ask those
questions, either by politeness or law, depending on the situation.
(Gender is usually pretty obvious though…)

I know, but privacy is a very young theme in Italy

4. another great feature, mainly for eGW but that would be very
   important for pERP too, could be the option to link a custom defined
   validation procedure/function to any custom field.

That would be a nice feature, but only applies to the text type.

Why only for the text type?

It could probably be implemented so you could provide your regex or
validation callback function as an option.

Well a regex, if I’m not wrong, could be used only to check the format. With a validation callback function one could do many more interesting things.

By the way, considering that we already have those codes (for our company,
clients and suppliers) in eGW Addressbook custom fields, it would be very
nice if pERP could recover or link to those data.

It can if the information is in the client’s billing address. It
doesn’t do anything in particular with it, but it is accessible.
How it gets accessed depends on how you want to use it.
For example, to add a client’s VATIN number from the addressbook
custom field ‘vatin’ to the invoice report, you need to add this to
the invoice report template:
[invoice.bill.#vatin;noerr;]

Do you mean that we have addressbook’s custom fields records (i.e. egw_addressbook_extra) of that client online when we create the invoice report? That’s great!

To display the addressbook’s custom fields in the client list would be
a little more complicated.

If custom fields records are online I know how to do it. I did something similar with addressbook because we have many custom fields and we don’t want to display them in a single long column.

Michele

[ngegw]

…
Nathan Gray wrote:

Or, if every company in Italy has these and that’s where everyone
already puts them, would a better place be as custom fields in the
addressbook? This would include your company’s own address record
easily.

… I guess this one could be an easier and more homogeneous way. This is
exactly what we do in eGW’s addressbook. And yes, every Italian company has
a VAT code (this is true for most European countries too); every Italian
physical person or company has a fiscal code.

Well, if that’s the case, we’ll go with that, in one form or another.
What should we do to make sure all Italians (and most Europeans)
create the correct custom fields? They can probably be automatically
created when pERP is installed into an existing eGW, but I don’t know
about full new installs.
Where do these need to appear? Invoice report is easy, you can
probably do that. Should they also appear on the client’s Details
tab?

Nathan Gray wrote:

2. we must distinguish if a client/supplier is a physical person or a
   company, and consequently consider private or company Addressbook infos
   (i.e. address, phone numbers, etc.).
   …
   It would be better if that report could made that choise looking at some
   addressbok categories (i.e. Company and Private). …

How about VAT or fiscal code? If it has a VAT, it has to be a company, right?

…
That would be a nice feature, but only applies to the text type.

Why only for the text type?

The other options don’t let the user enter unrestricted input.
Date, Date+time, label, check, radio, search, selectbox, button, URL,
email, select entry

I guess if you’re writing a callback function, there’s no reason why
it couldn’t be used for the others. You could only enter email
addresses from a certain domain, or select an infolog entry from a
certain category.

…

It can if the information is in the client’s billing address. …
[invoice.bill.#vatin;noerr;]

Do you mean that we have addressbook’s custom fields records (i.e.
egw_addressbook_extra) of that client online when we create the invoice
report? That’s great!

Yes, most reports that use an address will have it.
Company information from the address set in Admin -> pERP -> Site
config is also available on every report with
[company_address.field_name;noerr;]

Nathan Gray wrote:

To display the addressbook’s custom fields in the client list would be
a little more complicated.

If custom fields records are online I know how to do it. I did something
similar with addressbook because we have many custom fields and we don’t
want to display them in a single long column.

Sort of. With no code changes, you can look at the Work Phone column
for an example that uses eTemplate widgets to take care of it.

---

Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

---

Perp-developers mailing list
Perp-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perp-developers

[PCSLists]

Nathan,
congratulations for your initiative. Here in Brazil, one very common procedure about payments/receipts is to exist multiple due dates, for credit sales in several plots. One buy may have two or three payments for 30, 60 and 90 days, for example. Today pERP don’t do it, and we must to define one of the due dates for pERP management, while the others are not alerted. Would be very interesting to include various dates and pERP alert when each is near.

Best regards.

[ngegw]

Nathan,
congratulations for your initiative. Here in Brazil, one very common
procedure about payments/receipts is to exist multiple due dates, for credit
sales in several plots. One buy may have two or three payments for 30, 60
and 90 days, for example. Today pERP don’t do it, and we must to define one
of the due dates for pERP management, while the others are not alerted.
Would be very interesting to include various dates and pERP alert when each
is near.

Would these be equal payments, or could the amounts vary between payments?
The interesting part is in deciding if the invoice is overdue or not.
This would make several of the reports much more complicated…
Would it be sufficient to have some kind of popup on the invoice where
you could define an amount and a due date?

---

Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

---

Perp-developers mailing list
Perp-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perp-developers

[PCSLists]

Would these be equal payments, or could the amounts vary between payments?

The two options. Usually equal payments, but also happen of different amounts.

The interesting part is in deciding if the invoice is overdue or not.

It would be computed each due date. For example: In a suposed date of 01/04 an invoice that have due dates in 20/03 and 20/04 will be overdue for the first due date but not for second.

This would make several of the reports much more complicated…

I agree!! :-} I don’t know how to solve it.

Would it be sufficient to have some kind of popup on the invoice where
you could define an amount and a due date?

I think yes! Maybe invoices with several due dates could create several records for payment, each one with a due date and an amount, something like sub-invoices. We need mainly have control of payments amounts and due dates for periodic financial planning and cash flow.

[PCSLists]

Another question very important here in Brazil.
We use comma for decimal places and dot for the thousands. I set the preferences to do it, but in perp_ap>>payments and perp_ar>>receipts it’s not working!. If I write 250,30 the value showed in “total” is 0,00 but with dot it works!

[ngegw]

If I write 250,30 the value showed in “total” is 0,00 but with
dot it works!

Blame your browser that you have to use . instead of ,.
I finally figured out a way to do it, only took a few months.

---

Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

---

Perp-developers mailing list
Perp-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perp-developers

[MicheleT]

On Wed, Mar 24, 2010 at 8:50 PM, MicheleT michele.trulli@email.it wrote:

…
Nathan Gray wrote:

Well, if that’s the case, we’ll go with that, in one form or another.
What should we do to make sure all Italians (and most Europeans)
create the correct custom fields? They can probably be automatically
created when pERP is installed into an existing eGW, but I don’t know
about full new installs.

Why don’t you simply ask which custom field to use in each corresponding Site configuration form, just like you did with suppliers and clients categories? This way you can explain in help text that they need to define one or more custom fields in eGW if they want to manage those additional data in pERP. They can assign appropriate type, name and length to those fields too.
We could also use this same mechanism whenever we need to add more infos to some other pERP entity without the need to change or add tables in pERP db, or to duplicate data from eGW tables.

Where do these need to appear? Invoice report is easy, you can
probably do that. Should they also appear on the client’s Details
tab?

Yes, they must be there too. They’re very often the only way to tell a client/supplier from another one with the same name, so their presence will be very usefull in any client/supplier (selection) list or details tab.

2. we must distinguish if a client/supplier is a physical person or a
   company, and consequently consider private or company Addressbook infos
   (i.e. address, phone numbers, etc.).
   …
   It would be better if that report could made that choise looking at some
   addressbok categories (i.e. Company and Private). …

How about VAT or fiscal code? If it has a VAT, it has to be a company, right?

Right, but it may not be there for a reason or another. Also, if I know which kind of record they’re entering I can verify (with a validation function, of course) if they forget to enter a required field, or which data to use to check those codes.

…
That would be a nice feature, but only applies to the text type.

Why only for the text type?

The other options don’t let the user enter unrestricted input.
Date, Date+time, label, check, radio, search, selectbox, button, URL,
email, select entry

I guess if you’re writing a callback function, there’s no reason why
it couldn’t be used for the others. You could only enter email
addresses from a certain domain, or select an infolog entry from a
certain category.

That’s right, and with a callback function I can check if they enter uncompatible data (an end date < start date), etc.

Sort of. With no code changes, you can look at the Work Phone column
for an example that uses eTemplate widgets to take care of it.

I don’t remeber there were custom fields in Contact widget field selection box when I did that work! Is it a recent feature?
Anyway if we can use this widget in client list etemplate, it doesn’t seem so complicated.

Michele

[MicheleT]

Would these be equal payments, or could the amounts vary between payments?

The two options. Usually equal payments, but also happen of different amounts.

In Italy there other complications:
1) all invoice VAT paid immediatly or on first due date
2) due dates may be calculated starting from the invoice date (invoice date=Mar 28 => first due date=Apr 28, next due date=May 28, etc)
3) due dates may be calculated starting from 15th day of the month of the invoice date (invoice date=Mar 28 => first due date=Apr 15, next due date=May 15, etc)
4) due dates may be calculated starting from the end of the month of the invoice date (invoice date=Mar 28 => first due date=Apr 30, next due date=May 30, etc)
5) Payments amounts can be computed using varying percentages, manually inputed values, equal values.

Consider that usually users choose a payment plan to let the software prefill dates and amounts fields.

Would it be sufficient to have some kind of popup on the invoice where
you could define an amount and a due date?

I don’t thimk so. We’re talking about a complex payment plan that must be recorded in a dedicated table.

Michele

[PCSLists]

On Thu, Mar 25, 2010 at 2:15 PM, PCSLists <[hidden email]> wrote:

If I write 250,30 the value showed in “total” is 0,00 but with
dot it works!

Blame your browser that you have to use . instead of ,.
I finally figured out a way to do it, only took a few months.

Nathan,

forgive me, but I really don’t understood what means your answer. I don’t know what can I do about it.
I’m using firefox 3.5.2 and other with this same problem too, but it happens since before firefox 3.5 .
Do you have some suggestion for me?
Can you explain me??

Forgive me once more and thanks.

[ngegw]

Blame your browser that you have to use . instead of ,.

forgive me, but I really don’t understood what means your answer. I don’t
know what can I do about it.
I’m using firefox 3.5.2 and other with this same problem too, but it happens
since before firefox 3.5 .
Do you have some suggestion for me?
Can you explain me??

The reason that you couldn’t use , is because javascript does not
recognize anything but . as the decimal separator. Those particular
pages use javascript.

I have finally figured out a way around it, and it should be available
for you in the latest SVN.

---

Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

---

Perp-developers mailing list
Perp-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perp-developers

[PCSLists]

The reason that you couldn’t use , is because javascript does not
recognize anything but . as the decimal separator. Those particular
pages use javascript.

I have finally figured out a way around it, and it should be available
for you in the latest SVN.

It really was corrected for perp_ap>>payments and perp_ar>>receipts. Thank you very much.
However, I observed that it happen also in invoices screen, both AP and AR. When I put a value with comma in field “Unit Price”, it’s not recognized and appear “NaN” in “Price Line”.
Can you fix it too?!
Thanks

[ngegw]

…
It really was corrected for perp_ap>>payments and perp_ar>>receipts. …
Can you fix it too?!

Done.

---

Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

---

Perp-developers mailing list
Perp-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perp-developers

[PCSLists]

Thanks thanks thanks Nathan,

All ok!!!

Best regards.