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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Fwd: [ubl-dev] Multiple supplier account invoice


Hello Stephen,

First of all, thanks for the prompt feedback.

Interoperability is, indeed, the main issue preventing me from considering the use of extensions or customizations, that would then need to be implemented by the other parties involved in the UBL exchange process.

Considering your comments and the links that you have provided I'm guessing that there are only 3 options on the table (correct me if I got it wrong):
1) Use the AdditionalAccountID, even though it states that it refers to third party accounts, instead of supplier accounts;
2) Create a separate invoice for each account that is being billed;
3) Extend / Customize the UBL Invoice schema to the particular need that I'm describing.

I do agree that the schema does not provide great support for these kind of scenarios, where you want to bill multiple accounts.

However you said something that I wish to double check: As is, the AddicionalAccountID is to be used for this purpose in the current version of UBL?

Best regards,
Diogo Almeida

--


On Thu, Jan 29, 2009 at 7:36 AM, Stephen Green <stephengreenubl@gmail.com> wrote:
Sorry, when I said 'extend the Supplier Party' of course it should have
been 'extend the CustomerParty'.

Another way would be to extend the InvoiceLine to include something
like 'LineCustomerAccountID': then it is clear which account id goes
with which line. You might also want to restrict the CustomerParty to
remove the SupplierAssignedAccountID from it but that might be
unnecessary since you can simply suggest that it just doesn't get
used when there are multiple SupplierAssignedAccountIDs.

Again though, and for others reading this, I would avoid this customising
because you would lose the interoperability (especially in the software)
- unless interoperability is not your concern and you can influence the
software handling such a new invoice document type sufficiently to
warrant it, etc.

Best regards

Steve

2009/1/29 Stephen Green <stephengreenubl@gmail.com>:
> Hi Diogo
>
> As I remember it from the UBL TC at time of UBL 1.0, the TC added
> AdditionalAccountID for this kind of reason so it should be that you
> can use it. In UBL 2.0 the definition was refined at a late stage (after
> the first committee spec): I think that may mean that your comment
> should be considered for future versions of UBL. Some would say that
> using the AdditionalAccountID would be 'scope creep' but that means
> it would just be a form of customisation. The UBL principle agreed at
> an early date in UBL history was to cater for the 80% of requirements
> met by 20% of all the possible development that could have been done
> on UBL. Then to allow customisation to meet the other 20% of requirments.
> I think, personally, and you might agree, that an invoice covering multiple
> customer accounts for a single customer party is one of the 20%
> requirements best met by customisation. My gut feeling is that it would
> be clearer for the customer to have separate invoices but I haven't seen
> the exact requirements of your situation or scenario. If you have the
> opportunity to customise the  invoice, either its structure or its semantics
> or both then, after considering the guidelines (in progress)
> http://www.oasis-open.org/committees/download.php/29194/custguide091d.pdf
> (which might be being updated as I write - warning) I would just try applying
> your modified semantics to AdditionalAccountID or (if you prefer not to change
> the semantics) extend the SupplierParty structurally so that semantics do
> not have to change. Maybe you might consider adding a comment about
> this on the UBL comment list too if you are not a UBL TC member.
> http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ubl
>
> Anyway, the choice is yours how you deal with this. I would think that it
> might be tricky to identify which parts of the invoice correspond to which
> account ID so it seems safest to me to use separate invoices for each
> account ID. Then you can just use the Standard UBL invoice with just some
> subsetting (perhaps Northern European Subset or SystML or whatever).
>
> Best regards
>
> Steve
>
>
>
>
> --
> Stephen D. Green
>
> Document Engineering Services Ltd
>
>
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
>
>
>
> 2009/1/29 Diogo Almeida <diogo.borges.almeida@gmail.com>:
>> Good evening,
>>
>> In the process of creating an UBL 2.0 Invoice I ran into an issue regarding
>> the supplier assigned accounts.
>>
>> If I wish to create an Invoice where CompanyA bills CompanyB accounts 1 and
>> 2, where would I place such information within the invoice schema?
>>
>> The SupplierAssignedAccountID is an optional element that can only be
>> present one time per invoice. A somewhat possible option would be to use the
>> AddicionalAccount array element, provided that you ignore the fact that they
>> should be used for third party account identification, instead of additional
>> supplier account IDs.
>>
>> How could I represent this multiple account invoice notion in the UBL
>> Invoice schema, without the creation of an extension? I'm guessing that
>> either I've missed some place where this information can be placed, or just
>> its not a common scenario. Hopping for the first option, though.
>>
>> Has someone experienced similar requirement or situation?
>>
>> Would be very interested to know how would you approach this situation.
>>
>> Best regards,
>> Diogo Almeida
>>
>



--
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



--
Sem outro assunto de momento.
Melhores cumprimentos,
Diogo Almeida



--
Sem outro assunto de momento.
Melhores cumprimentos,
Diogo Almeida


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