1

I am working on integrating the A2A channel for the IRS through their WSDL using WCF. I'm able to get passed any code related errors sending the request but currently receiving the following error back from the IRS:

<faultstring>The message was not formatted properly and/or cannot be interpreted. Please review the XML standards outlined in Section 3 of Publication 5258 (...), correct any issues, and try again.</faultstring>
<detail>
    <errorcode>TPE1105</errorcode>
    <uniqueTransmissionID/>
</detail>

I'm assuming based on the additional node of <uniqueTransmissionID/> in the response it has something to do with the UTID. I've looked over the format of the UTID and the Soap Envelope examples countless times and can't for the life of me figure out what may be out of place. I tried a small suggestion by fatherOfWine in a previous answer of moving the BusinessHeader up above the Manifest but it returns the same error.

I've added the full request with the Soap Envelope, whitespace appears to be stripped during the request but I've re-formatted it coming from Fiddler.

POST [AATS URL] HTTP/1.1
Content-Type: multipart/related; type="application/xop+xml";start="<rootpart>";start-info="text/xml";boundary="--023e657d-66f5-4e92-8e6e-c223338c205a"
SOAPAction: "BulkRequestTransmitter"
Host: la.www4.irs.gov
Content-Length: 15820
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive


----023e657d-66f5-4e92-8e6e-c223338c205a
Content-Type: application/xop+xml; type="text/xml"; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Id:<rootpart>

<soapenv:Envelope xmlns:oas1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:us:gov:treasury:irs:ext:aca:air:ty18" 
    xmlns:urn1="urn:us:gov:treasury:irs:common" 
    xmlns:urn2="urn:us:gov:treasury:irs:msg:acabusinessheader" 
    xmlns:urn3="urn:us:gov:treasury:irs:msg:acasecurityheader" 
    xmlns:urn4="urn:us:gov:treasury:irs:msg:irsacabulkrequesttransmitter">
    <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
         <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <Signature Id="SIG-E508633998DD41B6AE062D27D0AC9A48" 
                xmlns="http://www.w3.org/2000/09/xmldsig#">
                <SignedInfo>
                    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
                    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
                    <Reference URI="#TS-BAC31544F1954B5F8C8441167B91A388">
                        <Transforms>
                            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                                <InclusiveNamespaces PrefixList="wsse wsa oas1 soapenv urn urn1 urn2 urn3 urn4" 
                                    xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
                            </Transform>
                        </Transforms>
                        <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                        <DigestValue>[VALUE]</DigestValue>
                    </Reference>
                    <Reference URI="#id-870747663BAB4D6FB43FFAD2034013F1">
                        <Transforms>
                            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                                <InclusiveNamespaces PrefixList="wsa oas1 soapenv urn1 urn2 urn3 urn4" 
                                    xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
                            </Transform>
                        </Transforms>
                        <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                        <DigestValue>[VALUE]</DigestValue>
                    </Reference>
                    <Reference URI="#id-1A336736A6134B16831D45A0C8785D10">
                        <Transforms>
                            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                                <InclusiveNamespaces PrefixList="wsa oas1 soapenv urn urn1 urn3 urn4" 
                                    xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
                            </Transform>
                        </Transforms>
                        <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                        <DigestValue>[VALUE]</DigestValue>
                    </Reference>
                </SignedInfo>
                <SignatureValue>[VALUE]</SignatureValue>
                <KeyInfo Id="KI-42CB9363E8BE47F2B3E0CD8A743C2D7C">
                    <wsse:SecurityTokenReference wsu:Id="STR-9EE1B09DD6794A64B00B496CC9DC3804">
                        <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">[KEY]</wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </KeyInfo>
            </Signature>
            <wsu:Timestamp wsu:Id="TS-BAC31544F1954B5F8C8441167B91A388">
                <wsu:Created>2018-12-27T17:42:39.593Z</wsu:Created>
                <wsu:Expires>2018-12-27T17:52:39.593Z</wsu:Expires>
            </wsu:Timestamp>
        </wsse:Security>
        <urn:ACATransmitterManifestReqDtl wsu:Id="id-DB1DDC6A020C433CB71FF38200026E55" 
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <urn:PaymentYr>2018</urn:PaymentYr>
            <urn:PriorYearDataInd>0</urn:PriorYearDataInd>
            <urn1:EIN>[EIN]</urn1:EIN>
            <urn:TransmissionTypeCd>O</urn:TransmissionTypeCd>
            <urn:TestFileCd>T</urn:TestFileCd>
            <urn:TransmitterNameGrp>
                <urn:BusinessNameLine1Txt>[Name]</urn:BusinessNameLine1Txt>
            </urn:TransmitterNameGrp>
            <urn:CompanyInformationGrp>
                <urn:CompanyNm>[Name]</urn:CompanyNm>
                <urn:MailingAddressGrp>
                    <urn:USAddressGrp>
                        <urn:AddressLine1Txt>[Address]</urn:AddressLine1Txt>
                        <urn1:CityNm>[City]</urn1:CityNm>
                        <urn:USStateCd>[ST]</urn:USStateCd>
                        <urn1:USZIPCd>[ZIP]</urn1:USZIPCd>
                    </urn:USAddressGrp>
                </urn:MailingAddressGrp>
                <urn:ContactNameGrp>
                    <urn:PersonFirstNm>[FirstName]</urn:PersonFirstNm>
                    <urn:PersonLastNm>[LastName]</urn:PersonLastNm>
                </urn:ContactNameGrp>
                <urn:ContactPhoneNum>[PhoneNumber]</urn:ContactPhoneNum>
            </urn:CompanyInformationGrp>
            <urn:VendorInformationGrp>
                <urn:VendorCd>I</urn:VendorCd>
                <urn:ContactNameGrp>
                    <urn:PersonFirstNm>[FirstName]</urn:PersonFirstNm>
                    <urn:PersonLastNm>[LastName]</urn:PersonLastNm>
                </urn:ContactNameGrp>
                <urn:ContactPhoneNum>[PhoneNumber]</urn:ContactPhoneNum>
            </urn:VendorInformationGrp>
            <urn:TotalPayeeRecordCnt>3</urn:TotalPayeeRecordCnt>
            <urn:TotalPayerRecordCnt>1</urn:TotalPayerRecordCnt>
            <urn:SoftwareId>[SoftwareID]</urn:SoftwareId>
            <urn:FormTypeCd>1094/1095C</urn:FormTypeCd>
            <urn1:BinaryFormatCd>application/xml</urn1:BinaryFormatCd>
            <urn1:ChecksumAugmentationNum>[CheckSum]</urn1:ChecksumAugmentationNum>
            <urn1:AttachmentByteSizeNum>[Bytes]</urn1:AttachmentByteSizeNum>
            <urn:DocumentSystemFileNm>1094C_Request_[TCC]_20181226T161942345Z.xml</urn:DocumentSystemFileNm>
        </urn:ACATransmitterManifestReqDtl>
        <urn2:ACABusinessHeader wsu:Id="id-E71242CFDF04487D9ECA0AC2E1544E90" 
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <urn:UniqueTransmissionId>6de74234-d0fd-45b2-ad45-b408fd137201:SYS12:[TCC]::T</urn:UniqueTransmissionId>
            <urn1:Timestamp>2018-12-26T16:19:42Z</urn1:Timestamp>
        </urn2:ACABusinessHeader>
        <urn3:ACASecurityHeader>
            <urn2:UserId>1#######</urn2:UserId>
        </urn3:ACASecurityHeader>
        <wsa:Action>BulkRequestTransmitter</wsa:Action>
    </soapenv:Header>
    <soapenv:Body>
        <urn4:ACABulkRequestTransmitter version="1.0">
            <urn1:BulkExchangeFile>
                <inc:Include href="cid:1094C_Request_[TCC]_20181226T161942345Z.xml" 
                    xmlns:inc="http://www.w3.org/2004/08/xop/include" />
            </urn1:BulkExchangeFile>
        </urn4:ACABulkRequestTransmitter>
    </soapenv:Body>
</soapenv:Envelope>
----023e657d-66f5-4e92-8e6e-c223338c205a
Content-Type: application/xml
Content-Transfer-Encoding: 7bit
Content-Id: <1094C_Request_[TCC]_20181226T161942345Z.xml>
Content-Disposition: attachment; filename="1094C_Request_[TCC]_20181226T161942345Z.xml"

<?xml version="1.0" encoding="utf-8"?>
    <n1:Form109495CTransmittalUpstream xmlns="urn:us:gov:treasury:irs:ext:aca:air:ty18" 
        xmlns:irs="urn:us:gov:treasury:irs:common" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:p3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xsi:schemaLocation="urn:us:gov:treasury:irs:msg:form1094-1095Ctransmitterupstreammessage IRS-Form1094-1095CTransmitterUpstreamMessage.xsd" 
        xmlns:n1="urn:us:gov:treasury:irs:msg:form1094-1095Ctransmitterupstreammessage">
        [Removed for Space]
    </n1:Form109495CTransmittalUpstream>
----023e657d-66f5-4e92-8e6e-c223338c205a--

Update: I added the Security Header and have gotten passed this specific problem, now working on resolving the WS-Security error. I've also updated my envelope with what has changed.

Das
  • 470
  • 5
  • 20

3 Answers3

2

Just throwing this out in the wind (more of a comment but too long), but it looks like you are missing these to elements from their example:

<urn4:ACASecurityHeader xmlns:urn4="urn:us:gov:treasury:irs:msg:acasecurityheader" />
<oas:Security xmlns:oas="http://docs.oasis-open.org/wss/2004/01/oasis-200401- wss-wssecurity-secext-1.0.xsd" /> 

You are using this prefix for urn3, which is not referenced in any elements from what I can tell. Not sure if it makes any difference or not, but the above to elements do precede the section that is giving you an error. Feel free to disregard if it sounds like non-sense to you.

Popo
  • 2,402
  • 5
  • 33
  • 55
  • 1
    Huh....I've used it with and without(before fixing a previous error) and didn't think it was required as some places in their documentation it says it's optional, but adding `[UserID]` is now giving me an error that is closer to getting to the full product! Thanks Mr. Popo! (I had to)....now to fix the dreaded `WS Security Header` error! – Das Dec 26 '18 at 21:29
1

I'd like to add to this, one of the things that I learned through developing this process a couple of years ago: the request you send, whether for status or submission, needs to be identical to their example.

The method I used to accomplish this was to create separate XML template documents (one for Submission one for Status) which contains the entire XML needed for each request.

At a high-level, my application uses the WSDL objects by populating them with appropriate data, then I replace the XML elements in the template with values from the objects, sign the XML document, attach the form data (for submission), and send the request.

Reviewing what you posted and comparing it to what I have previously transmitted, I found a couple of differences:

  • In your envelope definition, you have an attribute xmlns:oasl, I do not have this.
  • In your InclusiveNamespaces element, I have PrefixList="wsse wsa soapenv urn urn1 urn2 urn3". I was told having this literal value was a must.
  • Your DigestMethod is sha256, while mine is sha1. I understand there is a difference between the two, but this could be causing you some problems?
  • I have a urn3:ACASecurityHeader element containing a urn1:UserId element, which I think you have already resolved (its just not updated in your original post)
Russ
  • 678
  • 8
  • 26
  • They really (to this day!) need to go in and clean up their documentation(s). After reading over everyone else's solutions it sounds like the way to go! I've got a template at least setup for the envelope and was easy enough adding the `ACASecurityHeader` back to it. Now I'm getting the fun WS-Security error, you don't happen to see anything obviously wrong with the Security bits do you Russ? Before I post another question about it! lol Also going to try a different combo of the cert we have before doing so. – Das Dec 27 '18 at 16:33
  • @Das I have updated my post to include what I noticed was different between your and my envelopes. Hope this helps out! – Russ Dec 27 '18 at 19:02
  • Thanks for the update. I've been doing my best to mirror what's shown in 5.3.1.4 of their most recent Composition Guide (https://www.irs.gov/pub/irs-pdf/p5258.pdf) which has the new `oas1` namespace in the envelope and in their InclusiveNamespaces list(s). I believe I have all the Inclusives mirrored from that same example. I've updated my envelope with the SecurityHeader added and updates to the Security node itself. – Das Dec 27 '18 at 19:55
  • Going to try and change the DigestMethod for my References and see if that changes anything. AATS is apparently down right now so I'm in a bit of a lull until they pull it back up. I also noticed in 5.3.1.4 they are using SHA384....not sure if there is a list of methods they will accept or not, but I think my next step is to seek help from the AIR box. – Das Dec 27 '18 at 20:38
  • Adding another note here for anyone in the future. I got passed the WS Security error by following their new A2A checklist for TY2018 which apparently has changed some of the algorithms in the security bits. `DigestMethod` is now SHA256, `SignatureMethod` is RSA-SHA256 – Das Jan 03 '19 at 20:38
  • @Das Looks like my first attempt of the year to submit to AATS has bumped into a problem with WS Securuity. How did you end up setting the value for the algorithms of the `DigestMethod` and `SignatureMethod`? – Russ Jan 04 '19 at 22:01
  • 1
    For Signature before computing I added this line of code `signXml.SignedInfo.SignatureMethod = SignedXml.XmlDsigRSASHA256Url;` and where building the references I added `reference.DigestMethod = SignedXml.XmlDsigSHA256Url;` right after initializing the reference. – Das Jan 07 '19 at 14:51
  • @Das my turn! Adding your two lines, does generate the request using SHA256. I was able to sign the request, and verify the signature. So at least that piece is working as expected. Now, however, I am receiving a WS Security Error. I looked through the checklist and my code still appears to be compliant. I will post my code in a separate comment, maybe you can compare with yours and tell me what's different :) – Russ Jan 07 '19 at 17:14
  • Sounds good, I'm in refactor mode to clean up the "see what sticks" code I've got right now but I've gotten my transmission through to AATS so far. If it's easier for a new Q I'll be on the lookout lol. Another thing is to look at the new `oas1` I had to add in the prefix list(s) – Das Jan 07 '19 at 17:17
  • Thanks. I have added what I am submitting. I had noticed that while section 5.3.1.4 contains those elements, it also references TY17, instead of TY18. I will try adding the new `oas1` reference to the envelope element as well as to the prefix list and see what happens. – Russ Jan 07 '19 at 17:28
  • 1
    Yeah I've already sent them an email to update some of their samples, for instance they are using `urn2`(acabusinessheader) for the namespace of `UserID` when it should be the common NS. EDIT: I'll compare your envelope with mine and comment on any findings below – Das Jan 07 '19 at 17:33
0

Here is the envelope I am currently attempting to send which is resulting in a TPE1122 WS Security Header error being returned.

The following envelope XML is a working envelope for transmission for TY2018. Information has been redacted.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
                  xmlns:urn="urn:us:gov:treasury:irs:ext:aca:air:ty18" 
                  xmlns:urn1="urn:us:gov:treasury:irs:common" 
                  xmlns:urn2="urn:us:gov:treasury:irs:msg:acabusinessheader" 
                  xmlns:urn3="urn:us:gov:treasury:irs:msg:acasecurityheader" 
                  xmlns:urn4="urn:us:gov:treasury:irs:msg:irsacabulkrequesttransmitter">
    <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
        <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
                       xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <Signature Id="SIG-E9efb6eb0a76b4277a5cf8dc3930a868d" xmlns="http://www.w3.org/2000/09/xmldsig#">
                <SignedInfo>
                    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
                    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
                    <Reference URI="#TS-E057d0d55370e45a8bc8a42f995a89aa3">
                        <Transforms>
                            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                                <InclusiveNamespaces PrefixList="wsse wsa soapenv urn urn1 urn2 urn3" 
                                                     xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
                            </Transform>
                        </Transforms>
                        <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                        <DigestValue>[TIMESTAMP DIGEST VALUE]</DigestValue>
                    </Reference>
                    <Reference URI="#id-Ed6c3f891454e4eeaa73aeacaf21b6857">
                        <Transforms>
                            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                                <InclusiveNamespaces PrefixList="wsa soapenv urn1 urn2 urn3" 
                                                     xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
                            </Transform>
                        </Transforms>
                        <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                        <DigestValue>[ACA BUSINESS HEADER DIGEST VALUE]</DigestValue>
                    </Reference>
                    <Reference URI="#id-Eda32be00e9954326a8dbbd30a86a975e">
                        <Transforms>
                            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                                <InclusiveNamespaces PrefixList="wsa soapenv urn urn1 urn3" 
                                                     xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
                            </Transform>
                        </Transforms>
                        <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                        <DigestValue>[ACA TRANSMITTER MANIFEST DIGEST VALUE]</DigestValue>
                    </Reference>
                </SignedInfo>
                <SignatureValue>[SIGNATURE VALUE]</SignatureValue>
                <KeyInfo Id="KI-E70e6fef54fa44300bf8f732831579e03">
                    <wsse:SecurityTokenReference wsu:Id="STR-Ee23913563c7843c7917a3c63f9830d6f">
                        <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" 
                                            ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">[CERTIFICATE KEY IDENTIFIER]</wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </KeyInfo>
            </Signature>
            <wsu:Timestamp wsu:Id="TS-E057d0d55370e45a8bc8a42f995a89aa3">
                <wsu:Created>2019-01-07T16:32:54.353Z</wsu:Created>
                <wsu:Expires>2019-01-07T16:42:54.353Z</wsu:Expires>
            </wsu:Timestamp>
        </wsse:Security>
        <urn:ACATransmitterManifestReqDtl wsu:Id="id-Eda32be00e9954326a8dbbd30a86a975e" 
                                          xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            [MANIFEST DATA]
        </urn:ACATransmitterManifestReqDtl>
        <urn2:ACABusinessHeader wsu:Id="id-Ed6c3f891454e4eeaa73aeacaf21b6857" 
                                xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <urn:UniqueTransmissionId>e8d5fbcf-564d-4e31-8b48-ecc2fffe8fc0:SYS12:[TCC]::T</urn:UniqueTransmissionId>
            <urn1:Timestamp>2019-01-07T08:32:54Z</urn1:Timestamp>
        </urn2:ACABusinessHeader>
        <urn3:ACASecurityHeader>
            <urn1:UserId>[USER ID]</urn1:UserId>
        </urn3:ACASecurityHeader>
        <wsa:Action>BulkRequestTransmitterService</wsa:Action>
    </soapenv:Header>
    <soapenv:Body>
        <urn4:ACABulkRequestTransmitter version="1.0">
            <urn1:BulkExchangeFile>
                <xop:Include href="cid:1094C_Request_[TCC]_20190107T163254215Z.xml" xmlns:xop="http://www.w3.org/2004/08/xop/include" />
            </urn1:BulkExchangeFile>
        </urn4:ACABulkRequestTransmitter>
    </soapenv:Body>
</soapenv:Envelope>
Russ
  • 678
  • 8
  • 26
  • Removing the `oas1` prefix for me doesn't appear to change anything so I don't think that's it (why even show it, IRS!) Does your KeyIdentifier end like it shows or is it just redacted? Mine has proper closing brackets ``. This may be a stretch but you may want to check the expiration of the certificate? I remember when applying when we first tried with everyone else it was only valid for maybe 2 years. – Das Jan 07 '19 at 17:40
  • My `KeyIdentifier` element ends just as it shows. It looks like the expiration of the certificate is down the road a few months, so I should be good there. – Russ Jan 07 '19 at 18:00
  • 1
    If that is how it ends then you may need to look at how the `KeyInfo` is being built. It looks like it's missing the certificate entirely, mine looks (minus redactions) like this:` [Big Base64 Key Blob] ` – Das Jan 07 '19 at 18:13
  • @Das good catch! Thanks for letting me use your set of eyes! I was missing the reference to the certificate. Once I corrected that in my code, it appears as though my transmission sent correctly. I have updated my example with that and it is working code now – Russ Jan 07 '19 at 19:22
  • No problem, glad I could help! I'm sure I'll be throwing some more questions up now that I'm getting into the Status call...looking ahead was there any big change when you transitioned the code to production other than loading the "prod" wsdl or updating endpoints? – Das Jan 07 '19 at 19:46
  • No, the transition to prod has been seemless. If this is your first year transmitting, then I believe you have to call and get IRS to "sign-off" on your transmission to AATS being complete. Then they will enable you to transmit to prod. If you've previously transmitted to prod, you don't have to do anything else, (which is and has been my understanding). I have not had to do any extra things each year. – Russ Jan 07 '19 at 20:45
  • We are switching from UI to A2A and not too worried about dealing with them TTC-wise lol. I was talking more code/config changes, like managing the endpoints differently. I added the WSDL classes through the AATS WSDL specifically, I'm just wanting to make sure there are really no differences other than the endpoint on their end being switched from the AATS on to the PROD one. – Das Jan 07 '19 at 20:57
  • Not as far as I am aware. – Russ Jan 08 '19 at 00:06
  • I guess I'll just try updating the endpoint URI when we go prod and see what they bother me about lol – Das Jan 08 '19 at 15:22
  • You mentioned transmitting via UI, so I don't know if this will apply to you or not. After successfully transmitting via A2A and retrieving 'Accepted' status from AATS, you (someone with the ability to talk to them - Software Developer is ok) may need to call them in order to have them verify your transmissions are accepted. I think they will want the Receipt ID. Once verified, they will move your application to Production. I only had to do this initially; each year after I have only had to re-register the application for the next Tax Year, but not go through the AATS approval process. – Russ Jan 08 '19 at 19:22
  • So might need to create a question for this, but I have been working on this problem as well- my issue is the amount of unknowns for myself. Most of this is new for me. Currently working on the 1122. @Das and Russ what exactly is expected to go inside the KeyIdentifier element? The #x509v3 value type says it 'isn't in the scope' in the oasis docs. Would really appreciate a bit of help here. EDIT-- I initally thought it the public key value, but really unsure. – SteveManC Mar 13 '19 at 15:35
  • 1
    I'm using C# so you'd need to find anything equivalent but here's my way: I'm exporting my X509 cert to byte array and then using `Convert.ToBase64String(cert)` and using that string in the KeyIdentifier. – Das Mar 14 '19 at 15:59
  • @SteveManC I can confirm that I am doing what Das is doing. I am using C#. I have using the Export function of the X509Certificate2 object to export the certificate to a byte[], and then converting that to a Base64String (using the function Das mentioned) in order to get/generate the KeyIndetifierValue. – Russ Mar 14 '19 at 19:51
  • @Russ thanks for that. I'm doing the same, just through java. I've ran my file through validation (for the signature and references) pulling the certificate back out of the KI element and passed validation. Not sure where the problem lies at this point. I appreciate the response. – SteveManC Mar 14 '19 at 20:54
  • @Das did you have any issue sending in the status request? I was able to get through ( finally ) with my transmission, but now they don't seem to like something about my status req. :/ Probably going to follow up with a Question post showing what I have. – SteveManC Mar 20 '19 at 21:19
  • @SteveManC I'm currently able to transmit and get the status back, if you post up a question I'll try and be on the lookout for it and see what I can do! – Das Mar 22 '19 at 13:36