Re: [ubl-comment] Question about the BusinessCard object

[JAVEST by Roberto Cisternino <roberto.cisternino@javest.com>]

Hello David,
I cutted out some parts for a more readable mail.

Il 11/10/2017 20:46, David Goodenough ha scritto:

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.
What I want to say is that the BusinessCard is not binded to the DigitalAgreement process, it is mainly used to share or update Party information and any change in the time, that's why we designed a message.

At this point I think both the UBL-BusinessCard and UBL-DigitalCapability are required to changesome cardinality as follows:

Now we have these main parties:

SenderParty		1
ReceiverParty		1
BusinessParty		0..1

The meaning was that the BusinessParty is only necessary if the SenderParty is a third-party (such as a service provider).
The actual form was forcing implementers to fill the recipient and sender in any case (e.g. with a place holder) if the document was not immediately intended to be exchanged using B2B.

I see now a different priority:

SenderParty		0..1
ReceiverParty		0..1
BusinessParty		1

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.
This is facilitating the possibiity to publish (broadcast) a BusinessCard or a DigitalCapability on a web site or a public/private social or business directory.

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.
This structured way of describing digital services that we want expose and/or consume is based on an OASIS specification for business processes (BPSS) and projects like PEPPOL will find this structure quite familiar.  PEPPOL business profiles can be fully described using the UBL-DigitalCapability and trading party agreements can be built using the UBL-DigitalAgreement.

The BusinessCard can be used as a generic way of introducing your company to others and is not specific for achieving a Digital Agreement with our partners.
- I present my company with its trading capabilities for doing business (e.g. at a marketing level)
- I update my partners with my new business address or contact info
- so on... there are many uses for the Business Card. The main requirement was to have a way to transfer Party information separately from other specific business documents.

The DigitalCapability is *specific* for publishing only "digital" trading capabilities and building digital agreements. It contains Party information too, but NOT full trading capabilities.  A company could be able to receive electronic invoices and that's it... but their commercial capabilities could be many and detailed descriptions.... for that they will use a BusinessCard instead.

PEPPOL uses the name BusinessCard for digital purposes, but this is a simplification they probably preferred to use.
UBL TC seriously avoided to put all of these info inside the Party ABIE and we preferred to separate these documents for different purposes.

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.

VersionID		0..1	Identifies the current version of this business card.
PreviousVersionID		0..1	Identifies the previous version of this business card.

Versioning is accomplished using the upper information in the document root.

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).

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.

Please see the DigitalCapability and the DigitalAgreement more machine-2-machine documents for driving cyber-business not only e-business.
The BusinessCard is mainly an e-Business document and used mostly for human-machine relationships.

Do not see this as extreme, we have simply separated their roles.

I will immediately suggest the revision of the cardinality for the above mentioned documents, I will also request a fix for the specification where we miss the description for the DigitalCapability document (even if it is mentioned in the digital agreeement graph).  Further I will propose to include a graph for the BusinessCard too if possible.

Cheers,

Roberto Cisternino

UBL ITLSC, chair