Re: [ubl-dev] Mapping business model fields to UBL 2.0

[Stephen Green <stephengreenubl@gmail.com>]

As an aside, the obvious problem here seems to me that one cannot
really expect the other party to send atomic (which I take to mean
single-line) documents. Maybe a large buyer or a hub can do so. I'm
not sure even a national government would risk insisting on single-line

documents though. Surely it would be the same as insisting that many
parties replace their finance systems. Even tax authorities would not
dare insist on such large-scale changes when moving from paper to
electronic. Where there is leeway to design a system from scratch

however I tend to agree that one-line-per-invoice matching one-line-per-
order makes sense. I would think that the move from paper to electronic
would be contstrained by a requirement that the systems not (at least

in the first instance/phases) have to be replaced. Most of the existing
software for paper-based ordering and invoicing is surely going to be
essentially mutli-line. Then, once the systems are developed sufficiently

and have generated sufficient return on investment, then it might be OK
to look at replacing them with systems desgined specifically for electronic
documents. Even at this stage though, I'm not sure there is much to

be gained by trying to find a system which processes each document
atomically. Who would sell such a system? Surely they would sell systems
capable of multi-line documents and then the onus would be on the
user to decide whether to stick to one-line transactions; and if they do

what benefit would they perceive in keeping things that simple? Ken has
obviously perceived such a benefit or is open to the idea but the system he
uses is obviously designed to be able to handle multiple lines. I can only

imagine that an inhouse system might be less costly to convert to
electronic documents if the developers knew they would only need to
convert with atomic matches of invoice lines to order lines. They might like
the idea that they won't be getting an invoice for several orders but it would
be a luxury, surely, for them to think they can get away without having to
ever cater for more complex scenarios - unless they are developing something
point-to-point which has a huge potential disadvantage, folk assure me, of

lack of scalability. So I just want to put the other side to this. For scalability
it may be best to immediately consider that things are going to get complex
unless you have tremendous power to stop it - in which case you are

probably wielding some hefty B2B software capable of complexity anyway
and aren't in the business too much of looking out for the needs of the
little guy who cannot afford such stuff. Great if you do have the needs of the

small businesses in your supply chain in mind (I would happily stand up for
smaller businesses and their limited software capabilities in comparison with
larger business trading partners who so often call the shots). Even then,

though, I would think that saying to the whole supply chain or hub or
whatever that they have to use atomic documents all the time would be seen
as going too far and cause more problems than it solves - cost-benefit

analysis forbidding. Maybe a public sector heavy-weight might consider it
though so applause if they do. 
---
Stephen D Green
Document Engineering Services Ltd

2009/7/13 G. Ken Holman <gkholman@cranesoftwrights.com>

Thanks for the detail, Fulton!

At 2009-07-13 11:32 -0400, Fulton Wilcox wrote:

Below are a few comments that add some "best practices" comments

...

One of the preventative measures is when shifting from non-electronic to electronic invoicing, the buyer and seller parties (and tax auditors) are best served by making transactions as atomistic as possible, with one physical transaction generating a corresponding, specific electronic invoice.

...

Requirements such as "accounting details stated at document level must apply to all Invoice or Credit Note lines" are far easier to comply with for an atomistic level invoice transaction than for a highly aggregated invoice intermixing many transactions occurring over extended time.

It happens I'm tripping over this even today in reviewing last year's corporate numbers for a client who insisted on me invoicing each month a combination of hours actually performed in that month and pre-paid hours for some time in 2010 (thus meeting budgeting availability).  At the time I sent one invoice.  I'm now for tax reasons (it turns out I'm only being taxed on actual work not prepaid hours) trying to unwind what exactly I invoiced for and what was pre-paid.

In the text you cited from Sweden, point 8 reads:

8. stated pre-payments must apply to the Invoice as a whole

Would I have been better off having generated two invoices each month, one for actual hours and one for pre-paid hours?  In retrospect, my job this morning would have been a lot easier.

Come 2010, as I start using up the pre-paid hours, of course I cannot invoice the customer ... they've already paid me.  What kind of paperwork is used to record the "eating up" of pre-paid hours?

Thank you again for your input to the discussion.

. . . . . . . . . Ken


--
XSLT/XQuery/XSL-FO hands-on training - Oakland, CA, USA 2009-08-03
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org