[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Question about the BusinessCard object
On Wednesday, 11 October 2017 22:31:24 BST JAVEST by Roberto Cisternino wrote:
Hello David, I beg to differ, I think it is vital to UBL. There has to be a broadcast mechanism to allow the first non-broadcast interaction to happen. Lets say I am a customer, and I want to buy something from a supplier, and I am an SME with no admin/legal support, so no contracts and no lengthy negotiations. I need to be able to create a DigitalCapability object to send to the supplier so that they can reply with a DigitalAgreement and we can start trading. This should be as simple and painless a process as possible The question is how the data for the supplier's Party information gets into my system ready for inclusion in my DigitalCapabilitiy object. Well, the DigitalCapability already includes the Sender Party information, same as in the BusinessCard.
The meaning was that the BusinessParty is only necessary if the SenderParty is a third-party (such as a service provider).
Here the BusinessParty is always mandatory and both the sender or the recipient are information that can be optionally used or added in the future to send the document as a message. Excellent, that seems to solve the problem. Having it in DigitalCapability as well just eliminates a step, and that is always good. Thank you,
The obvious answer is a business card or similar broadcast object, which I download from their web site (so it is entirely generic). I load it into my system (minimal typing), and tell my system to use that information to build a DigitalCapability object describing my capabilities - probably that I will use email as the transport mechanism and in that I will supply my email address for replies - and then I use that same source of information - which is why I suggested adding the DigitalService object - to direct the request to the right place in the supplier system. This broadcast object does not have to be a UBL BusinessCard, but the requirement looks and feels like a job for a business card, and there is a UBL BusinessCard which is so nearly what is needed and from reading the UBL documentation plays no part in any UBL process. I am sorry I didn't get you perfectly when you said to add DigitalService... where ? Now DigitalService (a.k.a Business Transaction) is nested inside the Business process and its collaborations. No, with the removal of the change in cardinality for DigitalCapability there is no need for a DigitalService component in BusinessCard.
David, I never asserted that the UBL-Businesscard is not contributing on the digital world... in fact I provided you with several examples... such as the need to update a business party with my new bank coordinated or my new Tax ID.
But there is no process associated with the BusinessCard. If you look at my other thread about changes to Party information surely that has to be done using the DigitalAgreement as it is the only that is versioned. The BusinessCard is not (that I can see). And there needs to be a way for the other interactions to reference the version of the Party data that is relevant to this conversation, but then there is no provision for this anyway.
I think I had misunderstood, or rather not appreciated what VersionID and PreviousVersionID were versions of. Comes of not reading the whole line in the summary reports. The only remaining problem is how say an Invoice references a particular version of a Party, but that is a matter for the other thread I opened yesterday.
The upper usage is very important into real business. We do not send business cards only for describing Digital Agreements.
I was not saying it was part of the DigitalAgreement process (it certainly does not appear on the flowchart), I was saying it was a precursor. Somehow the whole digital interchange process has to start, and that would logically be done by a business card like mechanism - i.e. the broadcast of party information. Such a precursor needs to be defined so that the rest of the UBL defined processes can happen, and so that the Party data delivered is the right data for later use. Getting the DigitalService information in there as well would help as well. No, the BusinessCard cannot contain DigitalService this is already partof the DigitalCapability document and also you need to tell if you are able to expose or consume a DigitalService that's why we use the DigitalCollaboration (here you can describe bot sending and/or receival capabilities). As above, solved by changing DigitalCapability.
The DigitalCapability document is strictly associated to the DigitalAgreement and it represents a precious instrument for service providers.
I agree, I would see it as fundamental also for people using the service peer to peer (my interest). It would also be necessary for solving the Party change problem. Yes the Digital Agreement can be used for peer-to-peer too. Exellent, thank you!
David Cheers, Roberto Cisternino UBL ITLSC, chair |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]