Skip to main content

Test Home
You & IATA

Search

You are here: Home » Services » Financial Services » Simplified Interline Settlement » SIS Forums
  • Print this page
  • Share this page

Reclaim Rejections vs Valuation Rejections

This is a read-only copy of the discussions. To view the original, where you can reply, go here. For info on how to log in, please see the instructions.

Created by Lance L on 2010-09-29 11:49:28 Back to Topics

Reclaim Rejections vs Valuation Rejections

If our system produces an automatic rejection of ISC (reclaim rejection with reason code 1C) and we subsequently determine that a valuation error rejection (Reason code 1A)should be billed for fare, will these both be accepted by IS or will an error be generated due to multiple same-stage rejections against a single doc/cpn?
Replied by James S on 2010-09-30 08:47:04
They will both be accepted by IS.
 
Note that IS will add a "duplicate" flag before it creates the outgoing file (see element 71, IS-Validaiton Flag, of the RM record). This is just a "warning" to the billed party, but doesn't affect the technical acceptance of the files.
 
James
Replied by Konda R (Qantas) on 2010-10-07 03:07:31
This scenario seems to contradict RAM

CHAPTER A10 — Part 2, 4.1.4 that requires "Only one rejection memo can be raised for any billed item (that had been billed on a specific invoice as a single item), incorporating all reasons for the rejection in that rejection memo."

Not sure what the receiving carrier is supposed to do with the duplicate rejection?  If they reject, it wil only come back as a 3rd rejection. So, receiving carrier has to deal with an issue created by a carrier not following the RAM rules.  SIS should be enforcing the RAM rule more effectively.

Before you say it....let me ...."this is a RAM issue, can you please redirect to revenueaccounting@iata.org?"

 

Konda

From: IATA
Posted: Thursday, September 30, 2010 8:47 AM
Subject: Reclaim Rejections vs Valuation Rejections

They will both be accepted by IS.
 
Note that IS will add a "duplicate" flag before it creates the outgoing file (see element 71, IS-Validaiton Flag, of the RM record). This is just a "warning" to the billed party, but doesn't affect the technical acceptance of the files.
 
James
Replied by James S on 2010-10-07 06:11:01
Hi, Konda...
 
Actually, you're (halfway) wrong about me directing to the RA email address. :) And you've brought up a good example about the divergence between SIS and RA, and when things get redirected.
 
With that being said, a few points:
  1. I don't think that this contradicts the RAM. It allows a carrier to do things that the RAM doesn't allow, which I would contend is different than contradicting. There are many similar examples within IS, like allowing billings over time limits, because we've always held that IS is not RA and that enforcement of RA rules is the responsibility of the billed carrier.

    I'll be the first to admit that IS hasn't always held 100% true to that mantra, but I fully agree with the principle. Carriers have a lot of bilateral and multilateral agreements that differ from the RAM, and we don't want to get in the way of those. And there are a lot of smaller reasons why we don't want to be responsible for validating every rule in the RAM. We're also not going to validate against QF billing AA for a $50,000 coupon that you supposedly uplifted from JFK - BOS... that's not what SIS is here for.
  2. I'll also comment on your specific scenario and say that, yes, according to the rule you posted, it appears you would reject based on RAM rules. And IS would allow that. If the OA chooses to reject back, IS would also allow that.

    But that's no different than today in an unstructured paper world. Do you have a lot of situations in which OAs explicitly break RAM rules and when you reject they reject back?

    I'll also say that the rule from A10 which you posted goes against my understanding of what should be allowed in order to allow single-reason bulk rejections. I'm checking on this, but it doesn't affect my previous answer.

And this all flows into why questions about what source code to use, or what you're allowed to do, or how you deal with a carrier who doesn't follow the rules are redirected to the RA dept.

SIS is a transport mechanism that has it's own rules. Some track the RA manual and some don't. The SIS project (ie, me) will address what IS will allow you to do, and how IS will behave as a result. And if you show me a RAM rule, I'll make sure that IS will allow that to be done. Or, as in your above question, I could take a change request to make IS validation more restrictive. I'll tell you that IS will allow you to create a 2nd rejection for the above example, but not if that's the best/most accepted way to do it.

But all of the above examples are related to SIS and the IS side. At least right now, SIS won't take a change request for the RAM, or tell you what you're allowed to do if an OA doesn't follow the rules. Just like 3 years ago, these questions should be directed to the RA dept.

Hope that clears a few things up,
James

 
ADVERTISEMENT


Additional information

© International Air Transport Association (IATA) 2014. All rights reserved.