[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-comment] How to refer to a Party that is ancillary toatransaction
Answering the various comments of Patrick, Tim & Andrew:- There is a direct, and I would have thought, obvious connection between CONTACT and PARTY especially when you look at the relationship between aggregates (objects) in the model which is now available. A PARTY can either be an individual person or an organisation. A CONTACT is a contact person, or department, within an organisation, or indeed an organisation's place, e.g. as a GOODS RECEIVING CONTACT at a building site given as DELIVERY ADDRESS PARTY. In terms of Patrick's multi-part question, I would suggest that if he was ordering as an individual then he would give his details under PARTY. In the same sense, if the ordering was effectively he and his wife as a couple, they would be a single PARTY with the name Mr and Mrs Patrick (or more informal), in the same way as they can have a joint name on a bank account. If however he is sending something to 'someone' at an organisation, rather than an individual, then the 'someone' is a CONTACT (GOODS RECEIVING CONTACT) at the DELIVERY ADDRESS PARTY. As for Patrick and wife, if they were ordering from an organisation rather than as private individuals, they could be joint ORDER CONTACT name at BUYER PARTY, or indeed he could be the ORDER CONTACT and his wife the PURCHASE APPROVAL CONTACT (or vice versa depending on who's the boss!) Now to Andrew's comment. Indeed, just like EDIFACT, one could have a Party (NAD) or a Contact (CTA) with a qualifier. BUT, in reality, what does it gain you? You still have to name each possible qualifier, and you have to have a careful, high-quality, definition for each of the qualifier values. Maybe it is slightly restrictive, but in reality who in their right mind would want to be able to use any possible qualifier value for PARTY or CONTACT in an Order. In fact having a qualifier system proved excessive in EDIFACT, because you had then to write MIGs which restricted the range of qualifiers that you needed in a particular message. I think this falls into the "Damned if you do, and damned if you don't" category of life. On balance I think it is more positive to define the types of party that you may need in an order as part of the design process, which I believe is what we have done. Whether or not we actually need all eleven we currently have is questionable, (I'm not sure we do in reality), and if anyone feels we have omitted any then they should propose the name and definition. 'bye for now... Mike Adcock Standards & Security Unit APACS - Association for Payment Clearing Services Mercury House, Triton Court 14 Finsbury Square London EC2A 1LQ Tel: +44 (0) 20 7711 6318 Fax: +44 (0) 20 7711 6299 e-mail: michael.adcock@apacs.org.uk ********************************************************************** The opinions expressed are those of the individual and not the company. Internet communications are not secure and therefore APACS does not accept legal responsibility for the contents of this message. If the reader of this message is not the intended recipient, or the employee responsible for delivering this communication to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone to arrange for its return. Thank you. **********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC