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] Account Response and Application Response.



[==>SMW] See below. 
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Tuesday, November 22, 2005 7:04 PM
To: swebb@gefeg.com
Cc: ubl-psc@lists.oasis-open.org
Subject: Re: [ubl-psc] Account Response and Application Response.

i am not proposing deleting anything.  I am pointing out we have duplication. 

The Danish Govt proposed Account Response as a means of notifying the Seller Party that the Buyer had received the Invoice and would be processing it.

The Catalogue group proposed the Application Response as a generic means of notifying a party about acceptance or not (at an application level) of any documents. For example, the Seller notifying the Buyer that they have received a Request for Catalogue and would be processing it.  (Is this the one that looks like a 824? - it was based on EDIFACT APERAK)
[==>SMW] The APERAK is like the X12 997. It says I got the message and it did not have any technical errors, or these are the technical errors. The 824 actually reports errors that results from application processing like this amount is invalid, etc.  The APERAK and 997 validate before application processing (at the parser or translator level), the 824 during application processing.
 
Personally I think it very confusing to have both documents.
[==>SMW] The two document types including the types of acceptances or deviations that they report should not have any overlap. Both can be sent and report different information. Maybe Peter can take a look at both of them and provide input on how the Danish Govt plans to use the Account Response.

We should be able to rationalize these and have one document that satisfies both requirements.  If we agree with this, then the issue is what should it look like. 

Sylvia Webb wrote:
We need to find out who had a requirement for the document before we make final decisions to remove it. It's a little late in the development process to delete documents after they've been announced  in the public domain (Kavi) without spending the time to find the original owner, or spend the time to incorporate the requirements into another document that we do wish to keep.
 
When this process of determining what documents to add was in the Library Content committee, we spent a good amount of time validating the requests and justification. I'm hesitant to decide to remove it without further investigation. 
 
The document type is very similar to the X12 824 transaction. If the message is properly annotated, it should not be confusing.
 
Sylvia


From: Mark Leitch [mailto:ml@tritorr.com]
Sent: Tuesday, November 22, 2005 2:28 AM
To: Tim McGrath; ubl-psc@lists.oasis-open.org
Subject: Re: [ubl-psc] Account Response and Application Response.

I thought the Application Response was simply going to be an acknowledgement of receipt that could be used for any message.
The Account Response is the accounting equivalent of a PO Response (not simple !!) stating what the sender believes is wrong with a particular accounting document [line].
I see the requirement for the former but my personal opinion is that the latter should be removed as
  1. I think it’s confusing to have a non-tax document at that point in the process and
  2. realistically, this is going to involve human intervention and a phone call / email.

M

Mark Leitch




> From: Tim McGrath <tmcgrath@portcomm.com.au>
> Date: Tue, 22 Nov 2005 14:01:16 +0800
> To: <ubl-psc@lists.oasis-open.org>
> Subject: [ubl-psc] Account Response and Application Response.
>
> We still need to decide what to do about these two document types.  They
> both appear to do the same function (allow an application level response
> to a transaction), but they have different structures.  I would like to
> only use one.
>
> My simple assessment is the Application Response is based on the EDIFACT
> APERAK document  but the Account Response is designed to reference
> specific lines on documents.  Can we get some debate on this?
>
> NB whichever structure we agree on can i suggest we call it an
> 'Application' Response as I am not sure how it could be seen as  
> response from an 'Account'.
>
> --
> regards
> tim mcgrath
> phone: +618 93352228  
> postal: po box 1289   fremantle    western australia 6160
>
> DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business
> Informatics and Web Services
> http://www.docengineering.com/
>
>
>
>

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

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://www.docengineering.com/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
https://lists.oasis-open.org/archives/ubl-psc/200511/msg00029.html
lists.oasis-open.org
crawl=CC-MAIN-2022-21
13195
application/http; msgtype=response
sha1:GFNSF6BI4FMXVQESQDHF5JZVREJTHWPC
<urn:uuid:20c01bcb-0ebd-4788-86be-46015e1e06c8>
2022-05-20T18:30:37Z
34.233.166.49
text/html
sha1:XFTMXVEAQNLVFZFITWXBDPS4T6KRUOPI
<urn:uuid:b8d622f0-ffa0-43d4-90b6-0ca7e0e7181e>
https://lists.oasis-open.org/archives/ubl-psc/200511/msg00029.html
response
<urn:uuid:c3cf5d53-0d6c-4e16-b42f-6bccab569736>
isPartOf: CC-MAIN-2022-21
publisher: Common Crawl
description: Wide crawl of the web for May 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-200
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.3-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/