RE: To get things started....

[Todd Boyle <tboyle@rosehill.net>]

William J. Kammerer said,
> Todd Boyle "urge[s] the EWG to accord a high priority to publishing a
> common horizontal set of components at an early date.  This should
> include all party, product, location, contact and other aggregates
> necessary for the 30 million small and medium businesses (SMB's) in the
> US to begin automating their bookkeeping."  Todd explains that "[the]
> ongoing cost of printing and mailing paper checks, and altogether
> unreconciled bookkeeping mess are a national disgrace, running well
> above $100 billion/year."  >>I will not argue about wherever Todd
> came up with that $100 billion/year figure.

Here was my calculation.  http://www.gldialtone.com/survey_of_waste.xls

Whoops I was off by 1.9 Trillion
http://www.unece.org/press/pr2001/01trade04e.htm  or is that 2.9 Trillion,
Ray?
Oh well, a trillion here, a trillion there.. whatever.  If Ray Walker is
right, then every day we goof off here in Core Components is costing the
world $10 billion!  In fact, my recent post about qualifiers is the only
technical post for the past three days, so you guys owe me $30 billion!

> Todd should share with Core Components his idea (model) of what these
> "party, product, location, contact and other aggregates" look like.  It
> would be preferable that he not refer us to OAG, xCBL, Intuit and qbXML
> to find out for ourselves.

I have been working, quite persistently behind the scenes here, to get
NetLedger, Intuit and Intacct to work together and converge their XML
schemas (SMBXML, QBXML and Intacct XML)

I have some comparisons I've done privately but need their permission
to post their schemas and parts of the docs in order to talk about them.

I also have requested some indication whether the idea of standardization
is a dead issue for them.  Obviously, people will need to know that.

> I could provide a model of these aggregates, but they would probably look
> a lot like EDIFACT - so I implore Todd to come up with his own.

That is a lot of work ---and I will do it---as soon as these three vendors
give me permission to post parts of their docs.  My recommendation will
be that these SME XML's must converge a lot of things.  For example here
are three date formats and address formats used by the three companies.

IntAcct
     <datecreated>
        <year>2000</year>
        <month>8</month>
        <day>18</day>
    </datecreated>

   .Mailaddress: Optional. Mail address specific information.
   Mailaddress Sub Elements:
   .address1: Optional.
   .address2: Optional.
   .city: Optional.
   .state: Optional.
   .zip: Optional.
   .country: Optional

NetLedger

   <postDate>01/14/2001</postDate>

   <shipAddress>Bailey's Training Services&#xD;950 E. Algonquin
Road&#xD;Arlington
   Heights IL 60005</shipAddress>

Intuit (QBXML is not finished or fully documented but has clues:)

   <!ENTITY % DATETYPE "(#PCDATA)">

   <!ENTITY % AddressDataMacro "(Addr1? , Addr2? , Addr3? , Addr4? , City? ,
    State? , PostalCode? , Country?)">


The biggest problem with these XML interface schemas is that they have
processing commands deeply interwoven with all the business data
content.  Approximately the top 1/3 of the XML instances are going to be
invoking methods on the host or application.  This is how OAGIS BODs
work.  These three SME applications are more different in their
processing than in the content of the screens for a PO, invoice,
payment etc. so there are major dependencies in the schemas that are
just a distraction, if you're working on standardization.

There is a very huge need for separating processing logic from the data
content in A2A integrations with these products, if we are ever going to
get anywhere with integration with SME software.  Then we can all benefit
from the diversity in application services, not least these Vendors.

Business Processs and Collaboration Patterns work of ebXML for B2B
interactions needs to be extended across the border to the accounting
and business applications. These vendors are still stuck with the old
model of "my application, my interface".  That's ok-just 5 years ago
we were thrilled that a program even had an interface!   But now, the
interface language has to be understandable -we can't deal with a doctor
or a carpenter or a waitress if they speak a different language.  So,
they don't get a job until they learn the language of the country they
live in.

I think the Vendors are emotionally confusing the issue of standardization
of business process interfaces, with standardization like CORBA or DCOM.
When CORBA or DCOM or Sun's Java changes, it forces deep changes in your
code just to stay alive.  But the BP layer does not specify that level
of the protocol stack, any more than it contains business data like
shipping address or product codes.  The BP layer, TP layer and messaging
has been explained a lot better in the specs than what I'm doing here.

What the application is going to see coming from the TP and BP layers
to/from 3rd parties is precisely defined business documents, within a
very tightly defined set of request and response containers or sort of
framework.  The application vendor benefits because there is a data
dictionary, business docs, and a framework for specifying requests
and responses that is cross platform.

My job is to get some (bleepin') business vocabulary that I can
understand, and then buy some business collaboration manager (BCM)
software that does these service layers for my application, that
doesn't cost $4 figures.

http://lists.ebxml.org/archives/ebxml-bp/200012/msg00014.html
http://lists.ebxml.org/archives/ebxml-bp/200012/msg00020.html

Ok here is my own thinking and this is no guarantee.

The non-interoperable XML schemas from Intuit, NetLedger and Intacct
are useless in themselves.  You could design better data aggregates by
going to the user interface on these application to identify the kinds
of information they support, and then highlighting the corresponding
elements in in the Core Components dictionary with a marker pen.  This
would take about an hour.

You could identify the common requirements from among their control
structures
by simply reading the instance docs, and implementing them the standard
way with CPP/CPA and in the BPSS.  They all have very simple stuff like
login Id, company Id, transaction Ids, Add, Update, Delete, etc.  The fact
that ebXML didn't specify A2A integration is not really fatal, I think,
because you could still use the B2B oriented services to encapsulate your
own A2A/CRUD methods.  It is these methods that we need to get the Vendors
to standardize so we can stream them thru the BSI.  And Vendors will need
to figure out standards for accounting recognition events to local
applications, since ebXML BPSS doesn't seem to inform both parties,
simultaneously, of both sides of the reciprocal movements they have
executed.

I am a GL looking for A2A integration but all my clients are web
services companies and they are going to use BCMs to conduct
busines on the internet.  So, I can either ask them to install my
queer proprietary interface or learn how to talk to their BCMs.

Todd
Todd Boyle CPA   (425) 827-3107
9745-128th Av NE, Kirkland WA 98033
func architect, NetAccount AS, Oslo, NO
tboyle@netaccount.com  http://www.netaccount.com/
tboyle@rosehill.net  http://www.gldialtone.com/