http://ofbiz.116.s1.nabble.com/how-about-adding-a-paymentMethodName-to-PaymentMethod-tp169026p169030.html
> It may apply to all payment methods (I'm not really
> sure that it applies to all current payment methods,
> much less ALL that may exist), but it does not
> describe the payment method. It describes the payment
> method's child so it should go in the entity that it
> is describing.
>
> Following through with the approach of putting the
> field in PaymentMethod entity puts you in the position
> of modifying the data to fit the data model instead of
> keeping the data model flexible enough to fit the
> data.
>
> --- Si Chen <
[hidden email]> wrote:
>
>> I disagree. This is a descriptive note that applies
>> to all
>> PaymentMethods so why put it in the child entities.
>> If you had a
>> parent class which had a field that all inherited
>> classes should
>> have, shouldn't be in the parent class?
>>
>>
>>
>> On Jun 28, 2006, at 1:35 PM, Chris Howe wrote:
>>
>>> "Bank A general account" does not describe the
>>> PaymentMethod, it describes the credit card, the
>>> company account, the gift card, etc so that field
>>> should go on the CreditCard, etc entity. Now if
>>> you're using it as an alias for the Payment
>> Method,
>>> then you should create a PaymentMethodAttribute
>> entity
>>> and make a relationship between the two.
>>>
>>>
>>> On a side note. I've noticed a couple of fields
>>> getting added onto entities in svn that are quick
>>> fixes to gain functionality but cause a loss of
>> the
>>> entity's meaning. PaymentMethod.partyId is one
>> that
>>> quickly comes to mind.
>>>
>>> --- Si Chen <
[hidden email]>
>> wrote:
>>>> Hi everybody.
>>>>
>>>> What do you think of adding a field
>>>> "paymentMethodName" to
>>>> PaymentMethod, so a company can identify that
>> method
>>>> A is "Bank A
>>>> general account", etc. etc.
>>>>
>>>> Si
>>>>
>>
>