sql-ledger-users

Commerce ID

[Rodrigo R. <de...@fe...>]

Is there any posibility to add a new field to the client?
 
Here we have a commerce idetifier (cuit like security number) and we need
these number to be asociated to the client on every invoice...
 
 
thanks!

Re: Commerce ID

[Rod R. <ro...@su...>]

You could put it in the Notes field.  I used this method to add some 
attributes to Parts, using "keyword=value" instances.

-- Rod
   http://www.sunsetsystems.com/

On Wednesday 06 February 2002 11:38, Rodrigo Roman wrote:
> Is there any posibility to add a new field to the client?
>
> Here we have a commerce idetifier (cuit like security number) and we
> need these number to be asociated to the client on every invoice...
>
>
> thanks!

Re: Commerce ID

[John C. S. <js...@im...>]

Hello,

You could also use the first address line, at least until we get a
special field for this purpose.

Cheers,



John Christian Stoddart
Caracas - Venezuela

On Wed, 2002-02-06 at 15:38, Rodrigo Roman wrote:
> Is there any posibility to add a new field to the client?
>  
> Here we have a commerce idetifier (cuit like security number) and we need
> these number to be asociated to the client on every invoice...
>  
>  
> thanks!

Re: Commerce ID

[elizabeth z. <eli...@li...>]

Is the Commerce ID equivalent of an SIC (Standard Industry Code, now
being changed to an NAIC code) in the United States or is it like a
company Tax ID ? 

thanks
elizabeth ziph
The Linux Box Corp. 

, On Wed, 2002-02-06 at 15:27, John Christian Stoddart wrote:
> Hello,
> 
> You could also use the first address line, at least until we get a
> special field for this purpose.
> 
> Cheers,
> 
> 
> 
> John Christian Stoddart
> Caracas - Venezuela
> 
> On Wed, 2002-02-06 at 15:38, Rodrigo Roman wrote:
> > Is there any posibility to add a new field to the client?
> >  
> > Here we have a commerce idetifier (cuit like security number) and we need
> > these number to be asociated to the client on every invoice...
> >  
> >  
> > thanks!
> 
> 

Re: Commerce ID

[John C. S. <js...@im...>]

Hi,

This is a unique number that identifies the business at our local
equivalent of the IRS. Local law states mandatory use on all invoices,
receipts, etc. Thus an invoice will not only carry our number/code but
the customer's number/code as well.

Cheers



John Christian Stoddart
Caracas - Venezuela

On Wed, 2002-02-06 at 17:42, elizabeth ziph wrote:
> Is the Commerce ID equivalent of an SIC (Standard Industry Code, now
> being changed to an NAIC code) in the United States or is it like a
> company Tax ID ? 
> 
> thanks
> elizabeth ziph
> The Linux Box Corp. 
> 
> , On Wed, 2002-02-06 at 15:27, John Christian Stoddart wrote:
> > Hello,
> > 
> > You could also use the first address line, at least until we get a
> > special field for this purpose.
> > 
> > Cheers,
> > 
> > 
> > 
> > John Christian Stoddart
> > Caracas - Venezuela
> > 
> > On Wed, 2002-02-06 at 15:38, Rodrigo Roman wrote:
> > > Is there any posibility to add a new field to the client?
> > >  
> > > Here we have a commerce idetifier (cuit like security number) and we need
> > > these number to be asociated to the client on every invoice...
> > >  
> > >  
> > > thanks!
> > 
> > 
> 
> 
> 

Re: Commerce ID

[Oscar B. <os...@el...>]

Hi,

I am not sure if it is a requirement in all cases in Europe, but with 
certain transaction you are indeed obliged to indicate the customers (or 
the shipping address') VAT number as well.

Example:
Seller A
Buyer B
Warehouse C (logistics company for B)

When A, B and C are all in different countries (and this happens 
regularly to me) then A needs to have the VAT number of C on his 
invoice. This becomes even more important if B does not belong to the EC 
and A and C do...

Got it? he he!

In other words VAT is a pain in the b.. for which you better cover your ...

Cheers,

Oscar




John Christian Stoddart wrote:

> Hi,
> 
> This is a unique number that identifies the business at our local
> equivalent of the IRS. Local law states mandatory use on all invoices,
> receipts, etc. Thus an invoice will not only carry our number/code but
> the customer's number/code as well.
> 
> Cheers
> 
> 
> 
> John Christian Stoddart
> Caracas - Venezuela
> 
> On Wed, 2002-02-06 at 17:42, elizabeth ziph wrote:
> 
>>Is the Commerce ID equivalent of an SIC (Standard Industry Code, now
>>being changed to an NAIC code) in the United States or is it like a
>>company Tax ID ? 
>>
>>thanks
>>elizabeth ziph
>>The Linux Box Corp. 
>>
>>, On Wed, 2002-02-06 at 15:27, John Christian Stoddart wrote:
>>
>>>Hello,
>>>
>>>You could also use the first address line, at least until we get a
>>>special field for this purpose.
>>>
>>>Cheers,
>>>
>>>
>>>
>>>John Christian Stoddart
>>>Caracas - Venezuela
>>>
>>>On Wed, 2002-02-06 at 15:38, Rodrigo Roman wrote:
>>>
>>>>Is there any posibility to add a new field to the client?
>>>> 
>>>>Here we have a commerce idetifier (cuit like security number) and we need
>>>>these number to be asociated to the client on every invoice...
>>>> 
>>>> 
>>>>thanks!
>>>>
>>>
>>
>>
> 
> 


-- 
_____________________________________________________________

Oscar Buijten

Tel: +33.4.67.57.97.45
Fax: +33.4.67.57.97.46
GSM: +33.6.20.84.15.22

Email: os...@el...

Web:   www.elbie.com

Re: Commerce ID

[Paul S. <zi...@su...>]

In the EU the same thing is used, depending on country I have seen it 
been called VAT-number or community code.

By law community code has to be printed on all invoices (and it is 
recommended to do it also on all trade related documents) from the 
invoicing party.

In intra-EU trade printing of the purchasing party's community code 
makes it possible to invoice without VAT charged. Definitely this is a 
field which should be added to the customer and supplier tables (as well 
as print-outs like quotations, order confirmations, invoices).

Paul

Re: Commerce ID

[Dieter S. <dsi...@sq...>]

customer specific information such as a tax number, commerce number can be
recorded in the notes field. The notes you enter in the customer screen
are carried over when you create an invoice.


Dieter Simader    http://www.sql-ledger.org   (780) 472-8161
DWS Systems Inc.     Accounting Software       Fax: 478-5281
=========== On a clear disk you can seek forever ===========

On Fri, 8 Feb 2002, Paul Saris wrote:

> In the EU the same thing is used, depending on country I have seen it 
> been called VAT-number or community code.
> 
> By law community code has to be printed on all invoices (and it is 
> recommended to do it also on all trade related documents) from the 
> invoicing party.
> 
> In intra-EU trade printing of the purchasing party's community code 
> makes it possible to invoice without VAT charged. Definitely this is a 
> field which should be added to the customer and supplier tables (as well 
> as print-outs like quotations, order confirmations, invoices).
> 
> Paul
> 
> 
> 
> 
> 

Bug Report

[Philip R. <p....@li...>]

Hello everyone,

I found two things I think are bugs:

I'm using SL 1.8.2 and Mozilla

1) AP module -> Add transaction
when entering a new transaction the fraction amount of the invoice is cut 
off after saving the entry.
e.g. 80.60 becomes 80.00

2) AP module -> Payments
when entering a payment SL does not use the local fraction divider but the 
us default.
e.g. in Germany we use a comma instead of a dot
when entering 80,60 it becomes 80.600,00

Does anybody have the same problems?

Any help is appreciated.

Ciao,
Philip


--
LINET Services
Linux im Intra- und InterNet

Rebenring 33                                    Tel.:   0531-280 191 71
38106 Braunschweig                              Fax:    0531-280 191 72

http://www.linet-services.de
mailto:in...@li...

Re: Bug Report

[Guido B. <gd...@le...>]

> Hello everyone,
>
> I found two things I think are bugs:
>
> I'm using SL 1.8.2 and Mozilla
>
> 1) AP module -> Add transaction
> when entering a new transaction the fraction amount of the invoice is
> cut  off after saving the entry.
> e.g. 80.60 becomes 80.00
>
> 2) AP module -> Payments
> when entering a payment SL does not use the local fraction divider but
> the  us default.
> e.g. in Germany we use a comma instead of a dot
> when entering 80,60 it becomes 80.600,00
>
> Does anybody have the same problems?

We was resolve problem to force number value passed to sub format_amount in
SL/Form.pm function

We dont know, but in some situation the format_amout receive $amount
parameter with comma "," and not dot "."; obviusly the next code dont
elaborate value correctly.

Probably it is wrong programming of LC_LOCALE !???

SL/Form.pm___________________________________
.................
sub format_amount {
  my ($self, $myconfig, $amount, $dash, $vg) = @_;

  # GDO change ',' to '.' (LC_LOCALE problems!?!)        ## insert
  $amount =~ s/,/./;                                     ## insert
  # GDO END                                              ## insert

  # compensate for perl bug
  $amount = ($vg) ? $amount : sprintf("%.2f", $amount);
  my $negative = ($amount < 0);
.................
_____________________________________________

bye
Guido Brugnara

>
> Any help is appreciated.
>
> Ciao,
> Philip
>
>
> --
> LINET Services
> Linux im Intra- und InterNet
>
> Rebenring 33                                    Tel.:   0531-280 191 71
> 38106 Braunschweig                              Fax:    0531-280 191 72
>
> http://www.linet-services.de
> mailto:in...@li...


-- 
ing. Guido Brugnara tel.+39(461)390804 fax.396028
Leader.IT S.r.l.  (Leader Information Technology)
Strada della Pozzata, 41        www.leader.it/srl
38050 Villazzano TRENTO (ITALY)    in...@le...

RE: Commerce ID

[Jack W. B. <ja...@sf...>]

Dieter, et al;

I have been lurking on this list for a while, but this subject has such a
simple answer that I am de-cloaking to provide it. (Apologies in advance to
non-programmers who might be overwhelmed by coder-speak.)

Root has mentioned a version of the answer; simply provide some custom
fields in the table which can mean different things for different users. But
there is an extension of this concept that would add 0 to N custom fields to
everything without changing the existing tables!

Create a set of 'Custom Fields' tables. These would look like this:

CustFieldsHeader
----------------
ID
DisplayName
Description
ParentTableName (value should be actual table name to avoid confusion)
ValueType (Indicates how the value should be stored and retrived - optional)
FormHTML (Actual HTML to use in a form including the value - optional)
ReportHTML (Actual HTML to use in a report including the value - optional)

CustFieldsValue
---------------
HeaderID (foreign key to CustFieldsHeader.ID)
ParentOID (foreign key to 'OtherTable'.OID)
TextValue (note that all values could be kept as text to simplify the code)
NumericValue
DateValue

For each table you want to add a custom value for, you create a 'header'
record describing the custom value. Values added to the Value table would
use the OID of the 'owner' record in the parent table as the foreign key
(note that this might be PostreSQL specific).

Now you simply modify the code for any form that allows custom values to get
the the appropriate CustFieldsHeader records and add the custom fields to
the form. Same for any report. The values can be retrived in one of the
following ways:
  (1) Use a separate query for the CustFieldsValues based on an OID returned
from another query. (probably the simplest way to implement this)
  (2) Modify a parent table query to also retrieve
CustFieldsHeader.DisplayName and CustFieldsValue.TextValue (or whatever) and
treat them as key/value pairs. Note that this would require changing any
code that loops through a recordset to look for a key change to know it has
'actually' moved to the next record. (complex, but not too many changes to
code)
  (3) Create a query generator that reads the CustFieldsHeader records for a
particular parent table and then generates SQL query statements that include
custom fields. (complex, but something you can encapsulate into a re-useable
function, may require lots of changes to code)

Admittedly this seems a little bit complex at first, and above I told you
the answer was 'simple'. But if you look at this carefully you will see it
has the advantage of being something you can add to any table without too
much effort once the base work has been done. It also has the advantage of
being hugely flexible -- with the ability to allow users to add their own
custom fields to tables via a simple form. In the long run it really is
quite simple. I have used variations on this scheme to create extremely
flexible systems in the past and I know it works quite well.

Of course you are probably wondering why I don't just do it? Mostly because
I need to do paying programming work right now -- anyone want to pay me for
this? If you do then you should also send a few shekels Dieter's way as
well, for the excellent work he has done.

Jack William Bell

> -----Original Message-----
> From: sql...@li...
> [mailto:sql...@li...]On Behalf Of Dieter
> Simader
> Sent: Friday, February 08, 2002 8:12 AM
> To: sql...@li...
> Subject: Re: Commerce ID
> customer specific information such as a tax number, commerce number can be
> recorded in the notes field. The notes you enter in the customer screen
> are carried over when you create an invoice.
>
> Dieter Simader    http://www.sql-ledger.org   (780) 472-8161
> DWS Systems Inc.     Accounting Software       Fax: 478-5281
> =========== On a clear disk you can seek forever ===========
>
> On Fri, 8 Feb 2002, Paul Saris wrote:
>
> > In the EU the same thing is used, depending on country I have seen it
> > been called VAT-number or community code.
> >
> > By law community code has to be printed on all invoices (and it is
> > recommended to do it also on all trade related documents) from the
> > invoicing party.
> >
> > In intra-EU trade printing of the purchasing party's community code
> > makes it possible to invoice without VAT charged. Definitely this is a
> > field which should be added to the customer and supplier tables
> (as well
> > as print-outs like quotations, order confirmations, invoices).
> >
> > Paul

Re: Commerce ID

[Sergio A. K. <ser...@ho...>]

IMO your solution is too complicated for what is trying
to resolve and complicate the life of the programmer,
while the dieter's solution complicate the life of the
end user (and difficult to validate).

I second the motion of root, just add some "custom"
fields and everyone happy, a simple solution that
pass the KISS test.

if you *need* one of the custom fields to have non null
values you just add a constraint (or checks).
(as is the case for CUIT -tax number- for us)

another solution is to take advantage of pgsql dynamic
array field ("custom varchar(99)[]") and with one field
you can have all the custom fields you want.

but I prefer the simpler solution that is to add
some "custom_n" fields.

/sergio

----- Original Message -----
From: "Jack William Bell" <ja...@sf...>


> Dieter, et al;
>
> I have been lurking on this list for a while, but this subject has such a
> simple answer that I am de-cloaking to provide it. (Apologies in advance
to
> non-programmers who might be overwhelmed by coder-speak.)
>
> Root has mentioned a version of the answer; simply provide some custom
> fields in the table which can mean different things for different users.
But
> there is an extension of this concept that would add 0 to N custom fields
to
> everything without changing the existing tables!
>
> Create a set of 'Custom Fields' tables. These would look like this:
>
> CustFieldsHeader
> ----------------
> ID
> DisplayName
> Description
> ParentTableName (value should be actual table name to avoid confusion)
> ValueType (Indicates how the value should be stored and retrived -
optional)
> FormHTML (Actual HTML to use in a form including the value - optional)
> ReportHTML (Actual HTML to use in a report including the value - optional)
>
> CustFieldsValue
> ---------------
> HeaderID (foreign key to CustFieldsHeader.ID)
> ParentOID (foreign key to 'OtherTable'.OID)
> TextValue (note that all values could be kept as text to simplify the
code)
> NumericValue
> DateValue
>
> For each table you want to add a custom value for, you create a 'header'
> record describing the custom value. Values added to the Value table would
> use the OID of the 'owner' record in the parent table as the foreign key
> (note that this might be PostreSQL specific).
>
> Now you simply modify the code for any form that allows custom values to
get
> the the appropriate CustFieldsHeader records and add the custom fields to
> the form. Same for any report. The values can be retrived in one of the
> following ways:
>   (1) Use a separate query for the CustFieldsValues based on an OID
returned
> from another query. (probably the simplest way to implement this)
>   (2) Modify a parent table query to also retrieve
> CustFieldsHeader.DisplayName and CustFieldsValue.TextValue (or whatever)
and
> treat them as key/value pairs. Note that this would require changing any
> code that loops through a recordset to look for a key change to know it
has
> 'actually' moved to the next record. (complex, but not too many changes to
> code)
>   (3) Create a query generator that reads the CustFieldsHeader records for
a
> particular parent table and then generates SQL query statements that
include
> custom fields. (complex, but something you can encapsulate into a
re-useable
> function, may require lots of changes to code)
>
> Admittedly this seems a little bit complex at first, and above I told you
> the answer was 'simple'. But if you look at this carefully you will see it
> has the advantage of being something you can add to any table without too
> much effort once the base work has been done. It also has the advantage of
> being hugely flexible -- with the ability to allow users to add their own
> custom fields to tables via a simple form. In the long run it really is
> quite simple. I have used variations on this scheme to create extremely
> flexible systems in the past and I know it works quite well.
>
> Of course you are probably wondering why I don't just do it? Mostly
because
> I need to do paying programming work right now -- anyone want to pay me
for
> this? If you do then you should also send a few shekels Dieter's way as
> well, for the excellent work he has done.
>
> Jack William Bell
>
> > -----Original Message-----
> > From: sql...@li...
> > [mailto:sql...@li...]On Behalf Of Dieter
> > Simader
> > Sent: Friday, February 08, 2002 8:12 AM
> > To: sql...@li...
> > Subject: Re: Commerce ID
> > customer specific information such as a tax number, commerce number can
be
> > recorded in the notes field. The notes you enter in the customer screen
> > are carried over when you create an invoice.
> >
> > Dieter Simader    http://www.sql-ledger.org   (780) 472-8161
> > DWS Systems Inc.     Accounting Software       Fax: 478-5281
> > =========== On a clear disk you can seek forever ===========
> >
> > On Fri, 8 Feb 2002, Paul Saris wrote:
> >
> > > In the EU the same thing is used, depending on country I have seen it
> > > been called VAT-number or community code.
> > >
> > > By law community code has to be printed on all invoices (and it is
> > > recommended to do it also on all trade related documents) from the
> > > invoicing party.
> > >
> > > In intra-EU trade printing of the purchasing party's community code
> > > makes it possible to invoice without VAT charged. Definitely this is a
> > > field which should be added to the customer and supplier tables
> > (as well
> > > as print-outs like quotations, order confirmations, invoices).
> > >
> > > Paul
>
>
>
>