OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-psc] Pending FIRTG issues


Dear all,

Roberto cannot attend the today meeting ... but this morning I discussed 
with him about some changes to apply to the following issue list.

Line 4

Proposed solution

1) Remove the cac:SignerParty inside cac:PaymentMandate (because it is a 
duplicate of /cac:SignatoryParty)

2) Modify cac:Person by adding a PersonID (0..1) identifier by 
recommending to use the ISO20022 PersonIdentification schemes through 
the following attributes:
- @schemeID = [see ISO20022 codelist]
- @schemeAgencyID = [code for ISO]

3) Add a reference ID to point to the cac:Signature containing the 
specific electronic signature applied by the treasurer for the mandate 
information (cbc:SignatureID, cardinality 0..1, definition: "Identifies 
the related Signature applied by a signatory party (e.g. a Treasurer)"

Line 17

Issue: add a new WithholdingTaxTotal ABIE because the semantic meaning 
is not the same for TaxTotal

Reason: this tax total is showed into an invoice in a separate part 
because this is instead an "income tax" applied on the invoice and paid 
by the Debtor/Customer to the Tax Authority (thus in a different way 
compared to VAT).

Proposal: add the following sample to PayableAmount description

PayableAmount = TaxExclusiveAmount + [VAT] - [Withholding Tax]


Best regards,

Arianna

JAVEST by Roberto Cisternino ha scritto:
> Dear PSC,
>
> please find below the remaining FIRTG issues with pending actions or 
> just waiting to be processed, with additional information and a 
> solution provided.
>
> I included also an issue that was accidentally only partially solved.
>
> Attached the latest worksheet for reference.
>
>
> LINE
> 	FIRTG ID
> 	Pending Action
> 	Additional Info
> 	Proposed Solution
> 4
> 	FIRTG.05
> 	To check the use of SignerParty
> 	When the PaymentMandate information is provided into an  Order a 
> there are some additional requirements:
> 1) An addtional electronic signature on the Order applied by a 
> treasurer or a legal representative of a company or a delegate.   This 
> signature could be a separate and different signature compared to that 
> one applied by the issuer of the purchase order.
>
> 2) An identifier for the PaymentMandate Signer.  This is a "Person" 
> (employee) not a "Party" (de jure) requested by the bank to provide 
> his/her personal identification.
> In Italy this identifier is a Fiscal Code of the Person acting as a 
> treasurer, legal representative or delegate.
> ISO20022 uses a generic PersonIdentification and there is a codelist 
> with all PersonIdentification schemes (see: 
> http://www.iso20022.org/documents/External_code_lists/Payment_ExternalCodeLists_09June09_v5.xls)
> NOTE: This person identification ID is not available inside the XAdES 
> signature.
>
> 3) A reference ID to the cac:Signature containing the specific 
> electronic signature applied by the treasurer.
> 	The solution is as follows:
> 1) Remove current SignerParty inside cac:PaymentMandate
>
> 2) Add a SignatoryPerson derived by cac:Person.
>
> 3) Modify cac:Person by adding a PersonID (0..1) identifier by 
> recommending to use the ISO20022 PersonIdentification schemes through 
> the following attributes:
> - @schemeID = [see ISO20022 codelist]
> - @schemeAgencyID = [code for ISO]
> 6
> 	FIRTG.17
> 	To be updated by eDoCreator.
> 	Current disposition:
> The session information is not related to the document but to the 
> process.  We resolved to add a CollaborationID in order to correlate 
> the document with its process.  Session data cannot be added on the 
> way as the document could be signed. Add CollaboratioID in all documet 
> below ProfileID.  See remark for definition
> 	
> 9
> 	FIRTG-B.01
> 	Not complete
> 	We have accidentally forgot the 2nd part of this issue:
> 2) Add a new information item under PaymentMeans called 
> <cac:FinancingAccount>  (0..1)
>
> This is the separate financing account requested by the financial 
> institution, used for Trade Financing purposes.
> NOTE: The proposed solution on the right revises the name accordingly 
> to reflect its type.
> 	Add <cac:FinancingFinancialAccount>  (0..1) to the PaymentMeans
>
> 11
> 	FIRTG.06
> 	Waiting for further discussion
> 	The end-2-end identifier, as intended by ISO20022, is the same 
> concept of the cbc:InvoicingPartyReference we currently have in the 
> UBL RemittanceAdvice document.
> The definition is strictly that one provided by UBL 2.0, "The 
> Invoicing Party's reference to the payment, previously requested of 
> the Payer to accompany remittance."
> Into UBL this is a textual reference and not an identifier, but the 
> bigger problem is to clarify the relationship between this 
> reconciliation reference information and the Invoice line items.
> I think there is not a precise rule for this, as it is up to the 
> Invoicing Party to indicate one or more references for reconciliation 
> purposes.
> Such reference could be associated to a single invoice line item, a 
> set of line items, a complete invoice, more than one invoice and even 
> different parts of different invoices.
> The solution seems to be to provide this InvoicingPartyReference at 
> line Item and in the root of the document (RemittanceAdvice and Invoices)
> 	To be evaluated by Tim McGrath as this is a cross-domain information 
> transported end-2-end for reconciliation purposes.  Also it impacts on 
> many UBL documents (Invoice, RemittanceAdvice, ...)
> 16
> 	FIRTG-C.01
> 	(Was Rejected.)
> Now accepted by  PB, but structure is to be approved.
> 	Roberto Cisternino has further discussed with Peter Borresen to 
> clarify the requirement for an IssuerParty intended as a third party 
> providing the invoice issuing process in outsourcing.   Initially the 
> name "issuer" was overlapping with the actual issuer role, so it has 
> been decided to use a different terminology like 
> "OutsourcingServiceProviderParty" or "OutsourcingProviderParty".
> Specifically, an outer "OutsourcingServiceProviderParty" containing an 
> inner cac:Party would be preferred (same way AccountingCustomerParty 
> has been made), this way we could add an information item to qualify 
> the kind of outsourcing is provided.
>
>
>
> 	Add a new ABIE:
>
> OutsourcingServiceProviderParty (0..n)
>     - ID                                         (0..1)
>     - OutsourcingServiceCode       (0..n)
>     - Party                                     (0..1)
>     - ServiceContact                      (0..1)
> 17
> 	FIRTG-C.02
> 	To be discussed
> 	The WithholdingTaxTotal is either an Italian and Spanish requirement, 
> but it is a well know use case  where the Debtor (Buyer) is requested 
> to collect the tax for the Seller (Small and micro companies).
> The original FIRTG issue was not correct or clear enough about how the 
> Withholding tax total is working, so I point out below some important 
> information:
> 1) The payable amount total is net of the withholding tax.
> 2) The withholding tax is not part of VAT but it is an income tax
> 3) The withholding tax is calculated, like VAT, from the taxable 
> amount using a rate.
> 4) The withholding tax is a total amount to be showed separately
> 	The actual TaxTotal seems to be sufficient as the Withholding Tax can 
> be expressed using a different TaxScheme for that purpose and 
> separated from VAT.
>
> The issue can be removed, but a sample in the guidelines would be 
> preferred for this particular case.
> 19
> 	FIRTG-C.05
> 	Waiting fro further discussion
> 	If the account owner is a private person and not an organization, the 
> bank requires a Person identification (Fiscal code, SSN, Passport ID, 
> ...) of the account Owner.
>
> Example: In Italy the Owner's fiscal code is required (Codice Fiscale)
>
> NOTE: Uses the same "PersonIdentification" codelist above mentioned 
> (ISO20022)
> 	Add a cbc:OwnerID (0..1) to the cac:FinancialAccount
>
>
>
> Best regards
>
> Roberto
>
> -- 
>
> JAVEST by Roberto Cisternino
>
> <www.javest.com>
>
>
> 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
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]