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
