Iain,
the ui to manage the agreement terms is here:
https://demo.dejc.com:8443/accounting/control/login?agreementId=1001
However, you are right, currently there is not a field in the
AgreementTerm to store the alphanumeric id, hmmm....
Question for all: what about adding this field to the AgreementTerm entity?
<field name="termName" type="value"></field>
Jacopo
Iain Fogg wrote:
Jacopo,
Thanks for the suggestion; I'd overlooked the possibility of using the
agreement model. I also read Chris's concern about the appropriateness
of using agreements, but if you don't specify an expiry date for the
agreement, I don't see that that is a big problem.
I have a slightly more practical problem to consider - how the heck do I
configure my supplier ids!!! If I create (say) a "legal" term, then I
guess I could provide my supplier id as the "term_value". However, the
type of this field is numeric (numeric(18,2) on postgres). So if one of
my suppliers has assigned me an alphanum id, I'm hosed there.
The agreement_term_attribute table looks just the thing to store the id,
but I'm blowed if I can see where I can maintain this in the UI - have I
been working too hard and missed something?
Cheers, Iain
Jacopo Cappellato wrote:
Iain,
I'd suggest considering the Agreement/AgreementTerm entities: you
create an agreement between your company and the supplier, then add a
new term to specify the assigned id; when you start a purchase order
and select this agreement, the agreement term will be automatically
added to the cart/order/documents.
Jacopo
PS: IMO in general, for the future, we should consider to move
information to the Agreement data model: for example, with a concept
of a default agreement for sales orders, some of the fields in the
product store could be moved in the agreement etc...
Iain Fogg wrote:
I have a large number of suppliers that all assign me a different
customer number. Does anyone know how/where I can record this
information? I need to include the number on things like my purchase
orders.
The obvious place for such an attribute is with the
"party_relationship" (although since this could conceivably be
multi-valued, a new table ala "employment" would be better).
A short-term hack would be to simply store the information as a
"party_attr". For example, if my customer number with supplier XYZ is
1234, store (XYZ, 123) as a name-value pair in party_attr.
Have I missed something more obvious, like the correct place to
record assigned customer numbers?
Cheers, Iain
