[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: A near to be final review of UBL 2.1 W3C Schemas
Hello,
please find my "near to be" final review of UBL 2.1 schemas.
These are 15 section with possibly nested indications.
Regards
Roberto
--------------------------------------------------------------
Under "cac:PartyLegalEntity"
The "StakeholderParty" definition has several typing mistakes, the correct
sentence is:
An association to the list of stackholders who form a corporate or
consortium.
--------------------------------------------------------------
RemittanceAdvice:
The RemittanceAdviceLine is missing a cbc:InvoicingPartyReference
The cbc:InvoicingPartyReference available in the root is not sufficient.
This reference is issued by the payee (seller/vendor)
and the payer is requested to accompany the remittance with these reference.
There could be more than one reference for multi-invoice reconciliation
with payments
and this reference is not strictly 1-to-1 with a payment or with an
invoice, so it is up to the payee
to specify such reference in the remittance head or for each remittance line.
For example:
Remittance sample:
- Line 1 InvoicingPartyReference 123
- Line 2 InvoicingPartyReference 123
- Line 3 InvoicingPartyReference 123
- Line 4 InvoicingPartyReference 5678
- Line 5 InvoicingPartyReference 5678
- Line 6 InvoicingPartyReference 5678
NOTE: These references are the "ONLY" information guaranteed to be
transported across the banking channel (clearing system) until the end.
Please review the following complete sample of a credit transfer to show
the importance of such "reference" in the Financial Supply Chain:
(1) - PROCESS: INVOICING
B2B Channel: The Supplier issues an Invoice and provides one or more
"references" for end-2-end reconciliation.
[Customer/Payer]<---[Invoice]<---[Supplier/Payee]
(2) - PROCESS: PAYMENT
B2B Channel: The Customer send a Remittance Advice to the Supplier for 1
or more invoices using the end-2-end references requested by the Supplier
to accompany the remittance.
[Customer/Payer]--->[Remittance Advice]--->[Supplier/Payee]
Banking Channel: The Customer/Payer either directly or through an Agent
initiates a Payment Initiation on the banking channel by specifying the
end-2-end references requested by the Supplier.
The banking channel will transport such references til
the end and the Supplier will receive a Payment Execution
Advice containing such references for payment
reconciliation.
[Customer/Payer]--->[Payment Initiation]--->Banking Channel--->[Payment
Execution Advice]--->[Supplier/Payee]
(3) - PROCESS: RECONCILIATION
The Supplier/Payee receives both the RemittanceAdvice and the
PaymentExecutionAdvice and the reconciliation will be possible:
Finally end-2-end references can be matched between the Remittance Advice
and the PaymentExecutionAdvice,
this way payments and invoices are correctly related with the original
order/logic intended by the Supplier.
--------------------------------------------------------------
Invoice, FreightInvoice:
The Invoice head and the Invoice Line are missing the
cbc:InvoicingPartyReference
for the same reason above described for the Remittance Advice.
--------------------------------------------------------------
Inside Party:
1) The OutsourcedServiceProviderParty is not a correct business term and
is changing the intended meaning.
It should be:
"OutsourcingServiceProviderParty"
or just
"ServiceProviderParty"
2) The definition is to be defined:
Proposal: An association to a service provider party who acts as an
outsourcer.
3) Probably it could be better to change the cardinality as 0..n
--------------------------------------------------------------
Under "Statement Line", BalanceBroughtForwardIndicator:
Actual Definition: If true, indicates that the Statement Line contains a
balance brought forward.
Proposed Definition: If true, indicates that the Statement Line has a
balance outstanding from the previous bill(s)
--------------------------------------------------------------
FinancingInstrumentCode (0..n)
NOTE: I do not remember the requirement for 0..n cardinality.
The Financing instrument code should be 0..1 (or even 1..1) to
define which kind of TradeFinancing is adopted.
We have already the cac:TradeFinancing inside PaymentMeans so we
have already the chance of having different financing means.
--------------------------------------------------------------
TradeFinancing:
Move "ClauseCode" after "Clause"
NOTE: This is usally what we did with other couples of textual and coded info
--------------------------------------------------------------
Under PartyLegalEntity:
Add a new "CorporateStockNote" information entity after
"CorporateStockAmount"
Definition: Additional information related to the Corporate Stock Amount.
Example:
CorporateStockAmount = 1.000.000 EUR
CorporateStockNote = Fully paid-up capital
--------------------------------------------------------------
TaxIncludedIndicator
Definition is incomplete:
It should explain its difference from the TaxEvidenceIndicator
--------------------------------------------------------------
Under "TransportMeans"
JourneyID: This is the Carrier and/or Trade Service "JourneyID", fine,
but there are often a different JourneyIDs:
- used within consortium of carriers (e.g. United Feeder
Services, Inc.)
NOTE:In this case a Ship (or other means) is operating as
part of an alliance, but each party has a different Journey
ID (very bad yes!)
- used by Container/goods terminals.
NOTE: Container terminals are a good sample as mny different
carriers are visiting a terminal, thus using different
JourneyIDs that cannot be unique from the Terminal point of
view (every carrier has its voy counter and syntax)
That's why it is important to keep the relationship
between different Journey IDs.
I would suggest TSC to add other JourneyIDs with specified who is the
issuer/owner
--------------------------------------------------------------
Under "TransportMeans"
1) Another important information is the "Trade Service" which is a coded
information showing which is the regular service provided by that
carrier/transport mean.
- Add a "TradeServiceCode" and a "TradeServiceName"
2) I noted there is already a "OwnerParty" but it seems to generic for
expressing an important info like the shipping line.
The definition of this party could be tricky as usually we require a
specific "ShippingLineCode" and "ShippingLineName" information, for
instance.
I would suggest to provide a wrapper of the plain Party aggregate (like
we have for the AccountingCustomerParty in the Invoice)
For instance:
OwnerParty:
- CarrierCode 0..1 (e.g. SCL)
- CarrierShortName 0..1 (e.g. SAFMARINE)
- CarrierGroupCode 0..1 (e.g. MSK)
- CarrierGroupName 0..1 (e.g. MAERSK)
- JointServiceGroupCode 0..1 (e.g. UFS)
- JointServiceGroupname 0..1 (e.g. United Feeder Services)
- Party 0..1
- OperativeContact 0..1
NOTE: the Party still provides the possibility to specify the legal
name of the carrier and other possible info.
3) If not already available upper in the hieararchy (in a better place),
there could be the requirement of the following additional info:
- Add a "Customs Forwarder" 0..1
4) If not already available upper in the hieararchy (in a better place)
there could be the requirement of these additional info:
- Add a "MTOParty" (Multimodal transport operator) 0..1
--------------------------------------------------------------
Under "TransportMeans"
The "RoadTransport" is no more identified by a single Plate ID information.
For security reasons the Driver Surname and name or License to Drive ID
could be required together the Plate ID.
I suggest to enhance this part:
- by changing the "LicensePlateID" into "TruckPlateID"
- by adding a "DriverParty" or a "Person"
NOTE: the License to drive (if required) can be specified on either a
Party or Person aggregates.
--------------------------------------------------------------
Under "TransportMeans"
The "RailTransport" requires more information.
I suggest to:
- Change the "RailCarID" name to "CargoWaggonID"
- Add a DocumentReference to reference a specific Raylways document.
--------------------------------------------------------------
Under "TransportMeans"
The "MaritimeTransport" requires more information.
I suggest to:
- Add an "InternationalRadioCallSignID" (0..1)
This is a more common Vessel identification used in the shipping chain.
This is a unique identifier available from ITU where every Ship has a
radio call sign ID.
--------------------------------------------------------------
Under "cac:Person"
There is a missing a "PersonIdentity" information to be used to precisely
identify a person:
The PersonIdentity could be:
- IdentityDocumentReference 0..1
Samples:
- license to drive
- passport number
- SSN (Social Security Number)
- Fiscal Code
- ... so on
- Also a "DigitalIdentity" could be important as it is an actual
information worldwide.
Sorry here I do not have an idea of how we can provide this info !
--------------------------------------------------------------
--
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor
Roberto Cisternino
mobile: +39 328 2148123
skype: roberto.cisternino.ubl-itlsc
[UBL Technical Committee]
http://www.oasis-open.org/committees/ubl
[UBL Online Community]
http://ubl.xml.org
[UBL International Conferences]
http://www.ublconference.org
[UBL Italian Localization Subcommittee]
http://www.oasis-open.org/committees/ubl-itlsc
[Iniziativa divulgativa UBL Italia]
http://www.ubl-italia.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]