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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: Re: [ubl-lcsc] [Fwd: Italian implementation of UBL_Invoice]


just to let you know that we agreed yesterday to modify the cardinality 
of payment terms to allow many per invoice.  i hope when you see the UBL 
1.0 schemas in a few weeks you will find they meet your requirements.

Tim McGrath wrote:

> sonia,
>
> i will put your request onto this week's UBL conference call agenda. 
> as Jon noted earlier, we were not expecting UBL 0p70 to be used in any 
> production systems.  So it is surprising and useful for us to get this 
> detailed feedback. As you may be aware we are now finalising UBL 1.0 
> for trial implementation so we may be able to address your 
> requirements. either way, we shall let you know what your options are.
>
> monica, your point is well taken.  It does indicate a typical scenario 
> for the UBL trial implementations we hope to kick off next month. 
> however i am not sure if this is actaully a case of context or just a 
> better business rule being proposed.  the fact this is an italian 
> invoice seems irrelevant, it is the need for more than one payment due 
> that is the issue - is that requirement common/core (80/20)?
>
> with regard to contexts, we have plenty of use cases, now we need to 
> put into place the means of re-using and customizing UBL.  the context 
> methodology is only one part of the solution.  it will explain/define 
> HOW to restrict or extend the schemas.  what we also need is the 
> process that says, WHEN, WHERE and WHY to do this.  for example, let 
> us imagine that just because UBL does not have a BIE/element called 
> DUNS number , should an implementor create one as an extension?
>
> i think this debate should be a main part of the agenda for our 
> face-to-face as we move to UBL 2.0 work.
>
> Monica Martin wrote:
>
>> Chiusano Joseph wrote:
>>
>>> Ciao Sonia,
>>>
>>> I'll write to you in English because your English is excellent. I
>>> personally am not in a position to answer these questions for you, but
>>> I've forwarded your e-mail to the LCSC listserv.
>>>
>>> Molto piacere conoscerti,
>>> Joe Chiusano
>>>
>> mm1: This appears to be a use case for the context methodology 
>> subgroup to consider.
>> Thanks.
>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> Subject:
>>> Italian implementation of UBL_Invoice
>>> From:
>>> "Sonia Guerci" <sonia.guerci@isolutions.it>
>>> Date:
>>> Mon, 6 Oct 2003 18:57:28 +0200
>>> To:
>>> <chiusano_joseph@bah.com>
>>>
>>>
>>> From: Sonia Guerci
>>>
>>> iSolutions s.n.c.
>>>
>>> Noceto, PARMA (ITALY)
>>>
>>> Dear Mr. Chiusano,
>>>
>>> monitoring the UBL LCSC mail archive I’ve found that you speak 
>>> Italian, so I’m taking the liberty to pose a few questions.
>>>
>>> We are trying to develop a UBL compliant Web Service for electronic 
>>> invoicing.
>>>
>>> Basically we want to export and import invoice data in XML format 
>>> validating the files with the UBL_Invoice.xsd schema
>>>
>>> We’re experiencing problems fitting the fields of the typical 
>>> Italian invoice in the XML elements.
>>>
>>> Mainly we don’t know exactly where to place Payment Due dates.
>>>
>>> If I got it right the Invoice should contain the Seller’s 
>>> instructions that the buyer needs in order to trigger payment.
>>>
>>> The problem with the actual schema is that in the Italian invoice we 
>>> usually have more than one “payment due date”. Buyers have the 
>>> chance to pay a determined percentage of the ToBePaidTotalAmount by 
>>> each due date.
>>>
>>> We are now coping with this matter putting the entire description in 
>>> the element PaymentTerms/Note
>>>
>>> A typical PaymentTerms/Note that we use is “RI.BA. 30/60gg” which 
>>> translates to “Bank Receipt 30/60days”.
>>>
>>> If the Invoice/IssueDate was 2003/01/15 the buyer could pay, say, 
>>> 50% of the ToBePaidTotalAmount by the end of February 2003 and the 
>>> remaining percentage by the end of March 2003.
>>>
>>> Or the buyer could pay 100% of the taxable amount by one date and 
>>> 100% of the tax amount by the other.
>>>
>>> To effectively use the Schema we would need, for example, a 
>>> cardinality 0..n of SettlementPeriod and additional elements to 
>>> contain the percentages of ToBePaidTotalAmount and TotalTaxAmount 
>>> (ToBePaidTotalAmount - LineExtensionTotalAmount) due (or directly 
>>> the Amounts due).
>>>
>>> Something like this:
>>>
>>> <cat:PaymentTerms>
>>>
>>> <cat:ID />
>>>
>>> <cat:Note>*RI.BA. 30/60gg FINE MESE*</cat:Note>
>>>
>>> <cat:FromEventCode>*InvoiceIssueDate*</FromEventCode >
>>>
>>> <cat:SettlementPeriod>**
>>>
>>> <cat:DurationMeasure unitCode="*DAYS*">*30*</cat:DurationMeasure>
>>>
>>> <cat:TaxTotalAmountPercentRateNumeric>*50*</cat:TaxTotalAmountPercentRateNumeric 
>>> >
>>>
>>> <cat:LineExtensionTotalAmountPercentRateNumeric>*50*</cat:LineExtensionTotalAmountPercentRateNumeric>** 
>>>
>>>
>>> </cat:SettlementPeriod >
>>>
>>> <cat:SettlementPeriod>**
>>>
>>> <cat:DurationMeasure unitCode="* DAYS* ">*60*</cat:DurationMeasure>
>>>
>>> <cat:TaxTotalAmountPercentRateNumeric 
>>> >*50*</cat:TaxTotalAmountPercentRateNumeric >
>>>
>>> <cat:LineExtensionTotalAmountPercentRateNumeric 
>>> >*50*</cat:LineExtensionTotalAmountPercentRateNumeric >**
>>>
>>> </cat:SettlementPeriod >
>>>
>>> </cat:PaymentTerms>
>>>
>>> This would be great but increasing the cardinality of 
>>> SettlementPeriod should suffice.
>>>
>>> My question is:
>>>
>>> Is there a chance that the schema in the final release will allow 
>>> more that one payment due date? If not, do you see an alternative to 
>>> the use of the unstructured Note element?
>>>
>>> We would really appreciate any help you could give us.
>>>
>>> Sincerely,
>>>
>>> Sonia Guerci
>>>
>>> To unsubscribe from this mailing list (and be removed from the 
>>> roster of the OASIS TC), go to 
>>> http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php. 
>>>
>>>
>>
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php. 
>>
>>
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160






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