Extending the PaymentMethod entity and restricting PaymentAccount entity

[cjhorton]

Would it be bad form to:

1)extend the PaymentMethod entity so that the PK includes the paymentMethodId and the partyId?

AND

2)not allow duplicate PaymentAccount Number entries(in an entity similar to the EFT Account)?

With the OOTB PaymentAccounts, a user/multiple users can have multiple instances of the same CC or EFT Account Numbers.  For my application I am thinking this might cause some validation issues downline for us.  Basically, I would have only 1 instance of a PaymentAccount number that belongs to a party(Principal_Investigator).  Users can use this account which is why I would need the additional PK field on the paymentMethod entity.

I think I would need to remove the PaymentAccount update/edit feature.  Perhaps my lack of db design experience was just revealed.  Can you think of any problems the above may cause?

[BJ Freeman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suggest you use and SECAS triggered off of the CC or EFT account
creation to check for duplicates.

cjhorton sent the following on 2/28/2009 9:31 AM:

> Would it be bad form to:
>
> 1)extend the PaymentMethod entity so that the PK includes the
> paymentMethodId and the partyId?
>
> AND
>
> 2)not allow duplicate PaymentAccount Number entries(in an entity similar to
> the EFT Account)?
>
> With the OOTB PaymentAccounts, a user/multiple users can have multiple
> instances of the same CC or EFT Account Numbers.  For my application I am
> thinking this might cause some validation issues downline for us.
> Basically, I would have only 1 instance of a PaymentAccount number that
> belongs to a party(Principal_Investigator).  Users can use this account
> which is why I would need the additional PK field on the paymentMethod
> entity.
>
> I think I would need to remove the PaymentAccount update/edit feature.
> Perhaps my lack of db design experience was just revealed.  Can you think of
> any problems the above may cause?
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJqXinrP3NbaWWqE4RAvPfAKCsn5+s4Dnp6Y7sz6WYK8K2EVIcYgCfSu9M
oTCu1ofUTu7hII9fkWf8pGg=
=+QXH
-----END PGP SIGNATURE-----

[cjhorton]

Will do.  Thanks as usual.

On Sat, Feb 28, 2009 at 11:47 AM, BJ Freeman <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Suggest you use and SECAS triggered off of the CC or EFT account
> creation to check for duplicates.
>
> cjhorton sent the following on 2/28/2009 9:31 AM:
> > Would it be bad form to:
> >
> > 1)extend the PaymentMethod entity so that the PK includes the
> > paymentMethodId and the partyId?
> >
> > AND
> >
> > 2)not allow duplicate PaymentAccount Number entries(in an entity similar
> to
> > the EFT Account)?
> >
> > With the OOTB PaymentAccounts, a user/multiple users can have multiple
> > instances of the same CC or EFT Account Numbers.  For my application I am
> > thinking this might cause some validation issues downline for us.
> > Basically, I would have only 1 instance of a PaymentAccount number that
> > belongs to a party(Principal_Investigator).  Users can use this account
> > which is why I would need the additional PK field on the paymentMethod
> > entity.
> >
> > I think I would need to remove the PaymentAccount update/edit feature.
> > Perhaps my lack of db design experience was just revealed.  Can you think
> of
> > any problems the above may cause?
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJqXinrP3NbaWWqE4RAvPfAKCsn5+s4Dnp6Y7sz6WYK8K2EVIcYgCfSu9M
> oTCu1ofUTu7hII9fkWf8pGg=
> =+QXH
> -----END PGP SIGNATURE-----
>