(upbeat music)
-: So my name is Wes Vincent.
I work with the Bureau of the Fiscal Service.
I currently serve as the Product Owner
to the G-Invoicing application.
With me sitting at the table is Bill Schmidt.
He is the Principal Business Systems Analyst
with the Federal Reserve Bank of St. Louis.
We work daily with the development of G-Invoicing,
so he's gonna help me present a couple of slides
towards the latter part of the presentation.
Okay, so a couple of learning objectives we want to cover
before we get into the nitty-gritty
with the performance transaction.
What we're looking to discuss here,
is really a basic understanding
of what the performance transaction is,
and how to create those transactions within G-Invoicing,
whether that be through the user interface
or through system integration,
and then also one key aspect with performance
that's coming at a later date,
is the performance transaction's
going to initiate fund settlement,
and that's going to impact the IPAC application,
which many of you, or most of you I would assume,
use today to create payments and collections,
and then lastly, Bill is gonna really cover
the last bullet point here, but this really details out
how to extract the data, once the information
flows back from IPAC, and we'll cover this
with some more detail, but how can agencies
pull this data that's going to capture both G-Invoicing data
as well as IPAC Settlement Data,
and he'll cover those different scenarios
towards the end of the deck.
Okay, so a question before we begin is with the agency.
Currently in G-Invoicing, we have a set number
of different stages from beginning to end.
So, with a raise of hands, how many believe
that there is one stage in G-Invoicing?
Okay, so nobody.
How many believe that there are
two stages within G-Invoicing?
Okay, what about three stages?
So, we have some hands there.
What about four stages?
Okay, that's the majority, and then what about five stages?
There's the rest, okay.
So, if you chose four or letter D, you're correct.
However, if you chose three, you're not wrong.
So, it's kind of a trick question.
What I mean by that is, within G-Invoicing,
we have the GT&C, the order,
and the performance transaction.
So, if you attended this morning's sessions,
I hope you all did, to get a basic understanding
of what we're doing program wide
to the Chris Beck and Keith Jarvis presentation
earlier about the program overview and where we're at,
as well as Alex Abshire and George Pierce's presentation
covering the orders demo over in the Player Suite
right before lunch, they've given some really good information
about what is included in G-Invoicing.
And for those of you who weren't able to attend,
we're gonna just briefly cover this information
just to make sure everybody's on the same page,
but to get back to the question,
there are really four stages to the G-Invoicing lifecycle.
You have the GT&C which is your agreement level.
You then can create and approve orders.
Once those orders are approved, at that point,
you can do performance transactions against those orders,
and then upon completion of the performance transaction,
G-Invoicing is going to initiate fund settlements.
So that's the fourth stage.
However, in G-Invoicing, you have the GT&C,
the order and performance, so if you entered three,
we'll give you partial credit.
So, D is full credit.
Okay, so we're gonna spend a few minutes
and talk about really the whole program,
starting from the GT&C, down to fund settlement,
but this presentation is mostly going to focus
on the performance, and the settlement piece,
and how that's going to initiate fund settlement in IPAC.
So this slide really dictates there's four different stages
that we covered, the GT&C, the order,
the performance in IPAC, or the fund settlement.
The top row shows there's different stages.
The second row is the platform that really applies
to these different stages,
and it's kind of tricky with the fund settlement.
It occurs in IPAC, but it's initiated from G-Invoicing,
so it's a dual role there.
Both applications play a role, however,
the IPAC application is going to be the application
that actually creates the payment and collection document,
and then sends that information back to G-Invoicing.
So, the reason why it's not showing G-Invoicing there
is G-Invoicing does not actually create it,
it initiates the fund settlement, sends it to IPAC,
and IPAC will bring that back over,
or G-Invoicing will pull that back over.
The last row there, the bottom row,
is the Buy/Sell Business Events,
and that's just dictating what is being,
or what's occurring within each step,
so at the GT&C, we're gonna walk through these.
This is really the first step of the Buy/Sell process.
The GT&C section really identifies the general terms
that govern the different buy/sell activity,
in an interagency agreement between two trading partners.
In G-Invoicing both trading partners,
we refer to as the buyer as the requesting agency,
and the seller as a servicing agency.
So, this is where you initiate this ALC to ALC transaction,
and it's more of a high level documentation,
or a high level capture of information,
such as point of contact for the agreement,
the date range, the period of performance.
It also captures information such as roles
and responsibilities that will be needed
for the entire agreement,
and then also captures really main level data
for effective management of the IA in general.
So, moving on down to the next phase, we have the order.
One thing to keep in mind as we move through
the different stages on the slide,
is the fact that you cannot get to the next stage,
or you're not able to move on to the next stage
until you have full approval by both trading partners.
So again, this was touched base on a little bit earlier,
but it's really important to speak about this now,
as we talk through the stages, is that what we have today.
We talked about the IPAC wars, one thing that we have today
is some agencies simply IPAC, and that's it.
They don't have agreements.
They don't have orders in place.
If they have an ALC and a valid TAS/BETC combination,
and they have access to the IPAC application,
they can simply go into IPAC and bill,
or collect against the trading partner.
So what G-Invoicing is doing is setting up
a brokering system, all the way upstream
from the IPAC system to communicate effectively.
We've had that many times today, effective communication.
The GT&C level, the order level, and the performance level.
So, you aren't able to go to the order level
until both trading partners sign and approve
all the information that's been inputted onto the GT&C,
and it's the same for the performance transaction.
You cannot report performance against an order
until an order is fully approved by both the requesting
and the servicing agency.
So just keep that in mind as we move through.
We do require approvals on both sides
before we can move to the next step.
Okay, so once that order becomes open,
at that point an agency is then able to record performance.
So that third step, and where we're focused on today mostly
is the performance transactions.
So, when I say the GT&C and the order,
need to be fully approved, we actually capture signatures
from both trading partners at the GT&C.
There's two signatures, the initial and final,
and for both trading partners, and at the order level,
we have the funding and program officials.
They both have to sign.
That could be the same person,
created rules and permissions to be the same.
That's kind of dependent upon your business line,
but the main thing is we have to capture two approvals
by both trading partners.
The performance transaction, the third step here
is a little bit different in regards to
not having to capture an actual signature on the document.
So when I say approval, I mean,
I kind of put an air quote around that,
but an agency is not going to be approving or rejecting
their trading partner's performance transaction.
Yes, we do have measures to,
in essence, approve or show your approval
to your trading partner, but you're not going in
and applying a signature, or checking a box
with your name on it.
Each performance transaction is a standalone document
that would be submitted
by each trading partner.
So, we'll get more into that as well,
but that's one key difference between the performance
and from the GT&C, and order is it does not really have
an approval or a signature on the documentation.
Okay, and then lastly, the fund settlement.
So this is a new piece.
Again, you all are familiar with the IPAC application.
Some of you do the manual entry into the user interface
to create your payment collections.
I assume most agencies, or at least the larger agencies
would use the bulk file
to create these payments and collections.
So, that's going to continue being the application
that creates the settlement;
however, we're going to, when I say we,
G-Invoicing is going to initiate
that fund settlement for the agencies.
We think that's a really big benefit to agencies.
So, in the long run, we're eliminating the need
for agencies to transact within two different applications.
So, agencies will be going into G-Invoicing
from start to finish, and that will be it,
in the end game or the end result
of G-Invoicing, the final state.
Up until then agencies will still be able
to use IPAC as they do today, of course,
while they're onboarding and such,
but it's a big win that we think agencies need,
is instead of having to log into G-Invoicing,
and do a GT&C, an order, report performance,
and then log out or keep the browser open,
and go to a new session with IPAC,
and having to create something new in IPAC,
it's all happening in G-Invoicing, and all the data,
which is the most important piece to me,
is all the data is going to be available
back in the G-Invoicing once settlement occurs.
So we think that's a big benefit for agencies.
So slide five, really,
we're gonna dive deeper into performance.
We are gonna spend some time today going into some detail
about how to create performance,
what data elements are very critical to performance,
where they're agreed to,
when you agree to something what does that mean?
How does a performance transaction initiate settlement
to IPAC, and things like that.
So slide five really is a start of that.
What exactly is performance?
Performance is the delivery
and the receipt of goods exchanged
and/or services performed.
So, when we say performance,
again, we're not talking about how the system reacts
to a large number of transactions, or volumes,
or the security of the system, that kind of thing.
Performance is the delivery of goods or services rendered,
and how your buyer or your trading partner,
both trading partners react to that transaction.
So, specifically performance is something
that we don't capture today in the IPAC world.
That information can be out in your own systems;
however, that information is definitely not being
shown or communicated effectively enough
to your trading partner, and this is going to help
properly eliminate the differences that we have right now,
through the performance transaction.
So the second bullet there talks about the FIDS.
We've talked about this before.
A lot of my points have been stolen from me
from earlier presentations, but again it's important.
The FIDS are very important.
We do not have a standard set of data currently today
for IGT buy/sell.
I mean, we do now, because G-Invoicing created that,
but in the past, agencies have simply been using
different language, or they've been using different forms
to communicate the IGT buy/sell world.
So, for example, Fiscal Service has the 7600A and B forms.
I know many of you are familiar with that.
DOD may use NIPRs for example.
So we're not speaking the exact same language.
You might call an order number
or something completely different
than what your trading partner does.
So, we have FIDS, or the
Federation Intragovernmental Data Standards
at the GT&C level, we capture FIDS for the order level,
which is by far the biggest set of data that we have.
It's over 200 data elements.
That includes both trading partners,
required and optional fields,
and then we also capture FIDS
for the performance transaction.
The FIDS also includes from the performance transaction,
a handful of data elements that we have for settlement.
And what I mean, settlement is what happens,
IPAC needs to be tagged along to the performance.
So, specifically speaking, I'm talking about
the accomplished data that you see in IPAC,
that's on the FIDS.
We're talking about the do-symbols,
that's on the performance FIDS.
That information, I think there's four total data elements,
but the settlement FIDS is included in the performance FIDS.
So, we have three sets of data that's on the website,
the G-Invoicing website.
So, again we talked about this a second ago,
but one of the big benefits G-Invoicing
is providing the funds settlement.
This will keep everybody using one application
rather than two, and our Release 2.3,
which is the last bullet on slide five,
was deployed on July 11th.
So what that means is agencies can go into production
if they have accounts, and they have established
GT&Cs that are open, they have established orders
that are open, which, again,
that means both trading partners have approved
both sides of the GT&C, and the order,
you can then report performance.
So one key thing to take away from this piece here
is the fact that Release 2.3 enables agencies
to start using performance.
However, it does not initiate fund settlement.
That piece is coming at our next release,
Release 3.0, later this calendar year we believe,
in the October, November timeframe, or December timeframe.
He'll speak a little bit more about that in a few minutes
but up until later this calendar year,
you can submit performance,
it just will not initiate settlement.
So we've received questions from agencies about
how are we keeping transactions that are being recorded
as performance from being settled in G-Invoicing later?
So what we're doing is, we're assigning
every performance transaction in G-Invoicing
with the performance status of PRE, P-R-E,
and what that just lets us know as a system
is to not send this information over to the IPAC application
to generate settlement, once that functionality
becomes available later in Release 3.0.
So, we have a way to stop those transactions
from being entered, or from generating the IPAC settlement,
but we are asking agencies if you're ready
to start entering performance,
that information is out there,
that functionality is available.
It's been available since July,
so we hope agencies are wanting to jump into the system.
We know there's not gonna be
a lot of performance transactions out there
up until Release 3.0, but we're definitely welcoming
agencies to onboard and at least begin doing
their GT&Cs as soon as they can,
and then that will enable you,
once your your trading partners onboard
to get to the order phase, and once both trading partners
sign an order, at that point
they can both start reporting performance.
That will initiate settlement come later this year.
So, it's kind of a staggered approach,
but we definitely are welcoming agencies
to come in and start transacting within G-Invoicing,
and then, they spoke about this morning,
is the fact that we're, by the end of 2019,
we're looking at having full range
of functionality available for agencies,
all the way from the creation of the GT&C,
all the way through funds settlement,
so we think that's a really big win for the program
that allows agencies about a year and a half,
until the mandate date of June 2021
to get their information into the system
and be ready and adopt the practices that we have
and the guidelines that we have out there
on the G-Invoicing website.
So slide six, The Program Guide.
We've heard several people this morning
put a plug in for the G-Invoicing Program Guide,
so I'm going to do the same.
I think this is a tremendous document
that's going to help agencies out,
and it's going to really bridge that gap
between the transactions that happened
within G-Invoicing and the proprietary USSGL guidance,
and there's examples in the Program Guide to really reflect
how the transactions should be booked
and how they can properly eliminate.
So this is really tying the system
to the accounting entries, because again, G-Invoicing
is not booking the debits and credits for you.
We're providing the system, that brokering system
in between the two trading partners for agencies
and the Program Guide is really critical
to make sure you understand how this works,
and how to properly book the accounting entries
based upon the data input into G-Invoicing,
and agreed upon, so the Program Guide's really, really good.
I highly recommend checking this document out.
At 3:00 p.m. this afternoon,
so just in a couple of hours actually,
Chris Beck and Brian Castillo will be walking through
the Program Guide in more detail.
It's gonna be over in the Polara Suite.
So again, I highly recommend if you are available
to attend that session today at 3:00 p.m.
So please go check that out.
It's going to be worth your time,
and one thing to take with the Program Guide
is the fact that we are not,
as we move forward with G-Invoicing,
there's going to be updates made.
For example, we're currently working on accruals.
I'm not able to give great, great detail about accruals,
because we're still in the works of developing
how that's going to work, but accruals is gonna be
a vital piece of how you should be booking entries,
and that information is gonna be captured
in the Program Guide.
So, as we develop more policy,
we develop more functionality in G-Invoicing
and approve that functionality.
There's going to be tweaks to the FIDS.
There's gonna be tweaks
to the system interface specifications
that are posted on the website.
There's gonna be tweaks to the Program Guide.
It's a working document that allows agencies
to bridge that gap, so it's not a final state,
but it's definitely a working document
that we are gonna keep up to date
with the current functionality that we have
in G-Invoicing for agencies to use.
So again, please check that out at 3:00 p.m. this afternoon.
I definitely think it'll be worth your time and attention.
Okay, so on slide seven we're going to really talk about
the details of the performance transaction
and the data elements that trigger settlement,
and how this this all ties together.
What data elements at the order plays a part,
what data elements on a performance play a part.
So, the Freight on Board, or the FOB point,
and the Constructive Receipt Days
are really agreed to at the order header level.
So again, going back to that chart,
we have four stages, the GT&C, the order,
the performance, fund settlement.
The order has to occur before performance
can be reported against.
So, when you're documenting an order,
when you're creating the order,
and agencies are approving that documentation,
you have to agree upon an FOB Point
for the reported performance that will be coming downstream.
So what this means is, depending upon what FOB Point
you choose, whether that be FOB Point Source,
or FOB Point Destination is absolutely critical
into what's going to be happening downstream from the order.
So, once you choose FOB Point Source, and that's agreed to,
both trading partners sign off,
really the seller's performance transaction
is going to initiate funds settlement.
So I always think about it as FOB Source starts with a S,
seller starts with an S.
So FOB Source, the seller's performance transaction
initiates the funds settlement.
If you choose FOB destination, and that's agreed upon,
and approved by both trading partners,
the buyers performance transaction
will initiate fund settlement.
And it's not every performance transaction,
it's with certain performance transaction types.
So on this slide we talked about FOB Source.
The seller's going to initiate that
with a Delivered/Performed.
So we'll cover the performance types in more detail
in the slide or two, but for the seller,
the Delivered/Performed,
when you submit a performance transaction,
and you report a Delivered/Performance transaction
as FOB Point Source, the seller's going to initiate
that fund settlement.
If you report a performance as the buyer,
and its FOB destination, with a performance type of
Received/Accepted, at that point,
that fund settlement will occur, not when the seller
submits their Delivered/Performed.
So this is a very fundamental key piece
into what's going to be happening downstream,
and what's going to be what's going to be triggering
the initiation from G-Invoicing to IPAC.
So just keep that in mind as we move forward.
We'll walk through some scenarios with FOB Source,
and FOB Destination to really drill this in.
And the bottom part there with slide seven
kinda gets back to the Program Guide,
with the performance transactions being used
to communicate the exchange of goods delivered, or received,
and services rendered, for example.
So the Program Guide's gonna help link that
between the transactions within G-Invoicing,
and really what kind of accounting entries should be made.
That information is going to be captured
in the Program Guide.
So slide eight.
This is going to discuss
really the different performance types,
so we have four performance types that are available
for use by the trading partners.
As you can see on the right-hand side
of each performance type, we have in parentheses
which trading partner is able to use
these performance types.
So the first three, the seller is able to use.
The last one, the Received/Accepted
is the one that the buyer is able to use.
So when I say use, let's walk through a couple examples.
Okay, so the first performance type is Advance.
We'll just walk through all four of these.
The first performance type is Advance,
so, going back to that document
that had all four stages again, in order,
GT&C, order, performance, funds settlement.
At the GT&C you have to agree with your trading partner
whether you want advances
to be allowed underneath that GT&C.
We have an advance payment indicator data element
that's available at the GT&C header level,
and that has to be chosen as Yes or No.
If you choose Yes at the GT&C
for the advanced payment indicator,
at that point you're able to generate orders,
with or without advances.
It gives you the flexibility if you choose Yes.
If you choose No, every order underneath that GT&C
cannot be in Advance, it has to be a non-advance scenario.
So what if you have an example,
we always talk about being flexible for agencies,
allowing agencies to have an umbrella,
or a blanket type agreement that expands,
maybe 10 years or however long.
We give agencies the ability to really expand
that GT&C for a wide range of reasons.
Maybe you have 100 orders you want to use
underneath that one GT&C blanket umbrella.
By choosing Yes, you could have 50 order lines
that were schedules that have Yes.
You may have 50 that don't have advances,
but if you choose No, all of those have to be
non-advance scenarios.
So, because we laid that out,
now let's move to the order piece where you have,
let's say you do a GT&C with Yes indicated.
At that point, you can do an order that has advances or not,
so let's say you do an Advance for order schedule.
Okay, at that point, once you have an Advance
with an order schedule, you can report performance
with a performance type of Advance.
If you have an order line schedule
that does not allow an Advance,
you're not going to be able to submit
an Advance performance transaction type.
That doesn't make any sense.
So we're putting system limitations in place
to allow advances, when it's allowed,
when it's agreed upon, upstream at the order,
and if you don't agree to having Advances and you choose No,
you are not allowed to do
Advance performance transaction types.
Okay, so the second performance type that we have
is Deferred Payment.
So this performance type really is used for scenarios
such as work in progress,
to where maybe you're performing work,
and you want to document what you've done.
Maybe you've delivered 100 hours of service to somebody,
or to your trading partner,
but you want to collect at a later date for example.
At that point, you would enter in a Deferred Payment.
And then I also want to put,
I know we spoke a little bit about accruals,
so this is a major piece of the differences
that we see between agencies and we're working now,
with the development team and FRB St. Louis,
and the program team within Fiscal Service
to come up with a way to calculate accruals
for accrual reporting.
All this information we're looking at
really into our next section.
Our next release after Release 3.0,
so more to come on that, stay tuned.
We think it's gonna be very helpful for agencies
and a lot more intuitive than what it is today,
but Deferred Payment would be part of that accrual balance.
If you want to submit a Deferred Payment,
we're thinking at this point,
that could be part of the accrual balance
that we're looking into, so more to come on accruals.
I just wanted to throw that little plug in there
that it's important we understand that it's very important,
especially in regards to the differences in the numbers.
So, we're working towards that, and the Deferred Payment
will be a really an integral piece
of how we are doing accruals moving forward.
So the third performance type
that we have is Delivered/Performed.
I would say the next two are going to be by far
the most common performance types that we'll see
in G-Invoicing, and definitely the most transactions
involved will include these two performance types,
number three and number four.
So, the Delivered/Performed is again seller only.
The buyer is not able to submit
a Delivered/Performed transaction.
The seller will submit that,
initiate the performance transaction with this,
and then the last performance type that we have
is the Received/Accepted, and that's the only one
that the buyer is able to submit.
What would happen in a happy path key scenario would be,
I know Mike Linder used 100 units earlier,
so we'll use that example.
If it's FOB Point Source.
Again, that means a seller's transaction,
a performance transaction is going to
initiate funds settlement upon
when they submit a Delivered/Performed transaction.
So, let's say I'm the seller and Bill is the buyer,
and we have FOB Point Source agreed,
way back at the order level.
So as the seller, I'll go in and say,
I've delivered Bill 100 units.
Because it's FOB Point Source,
when I submit that Delivered/Performed,
that settlement's going to be initiated
into IPAC automatically.
We're not waiting on a response from Bill.
He doesn't have to supply anything,
that fund settlement's gonna be triggered
right when I submit the Delivered/Performed,
because of FOB Point Source.
He has the option to say.
Bill: Wes is a liar.
-: Yes, for example, that caught me off guard.
(audience laughing)
All right, I gotta get back to where I was at.
(audience laughing)
So, let's say I am a liar, and I say I've delivered you 100,
but I only delivered you 80.
So, instead of you saying nothing, and just accepting 80,
you want to document what you actually received.
However, the IPAC is going to be initiated from my 100,
because it was Delivered/Performed FOB Point Source,
just keep that in mind.
There's always, the first transaction is going to settle
Delivered/Performed with FOB Point Source.
So what he's doing in regards, in this situation,
is documenting, hey, I've only received 80,
so there's a discrepancy.
You said you delivered 100,
I've only received 80, what gives, other than being lying.
So, that's not going to trigger an IPAC settlement.
His transaction of Received/Accepted 80,
is not going to trigger an IPAC.
Why, because FOB Point Source.
So what in this situation would be,
there's a lot of rules that we have in place in G-Invoicing.
I'm definitely not gonna cover that in today's session.
That gets very, very, very detailed,
but that information is captured
on the system interface specifications
that are posted on the G-Invoicing website.
So what he's doing by showing a received 80,
instead of 100, is documenting the difference.
Until the Delivered/Performed matches the Received/Accepted,
that order cannot be closed.
So just restate that, is once those two things are reported,
they have to be in balance in order for that order to close.
It's very, very critical.
If I have a delivered of 100, and received of 80
on that line, that order cannot be closed,
until either I make an adjustment and say okay, I lied,
and only gave you 80, so I have to adjust that down by 20,
or Bill simply collects 20 more at a later date,
and at that point, he would just collect 20 more
and now our balances of 100 and 100 equal,
and then you can close your order.
So what he's doing is documenting the difference,
and that's going to be captured on a difference report
that we'll be developing to show you know when these things
are out of sync, or out of balance.
So, more to come on that as well,
with the difference report, but these are just a quick,
well kind of a quick, a run through of the performance types
that we have, and which trading partner
really is responsible for supplying that.
So on slide nine,
we're going to really cover
the scenario FOB Point Source in more detail.
So we're gonna kind of cover FOB Point Source first.
I kind of already did that, but we'll get into more detail,
and then we'll cover the FOB Point Destination
and what that means with Constructive Receipt days.
I know many of you have heard of Constructive Receipt days,
so that'll be the next piece that we'll present.
So, with FOB points source, again,
the seller's performance transaction type
of Delivered/Performed is going to
initiate funds settlement, not the buyer saying,
I've Received/Accepted X amount.
It's the seller's responsibility of sending that in,
and that's going to initiate fund settlement.
So we've already covered the straightforward
happy path scenario with the seller delivering 100.
At that point it's triggering settlement.
He can either say, hey I've received 100.
At that point they match, or he can say,
hey, I don't have to do anything
'cause it's FOB Point Source.
If the buyer goes in and submits a Received/Accepted,
if they match, that's fine.
If they don't match, we're gonna show that
on the Difference Report, and the order cannot be closed.
So it's up to the buyer, if they want to document that
on their side, to keep that as a difference.
When I say difference, I don't mean
an elimination difference.
I mean that order simply will not be able to be closed
until those balances equals the Delivered/Performed.
There's several different business cases, so if you can,
take a look at the system interface specification document,
and that labels out all of these different scenarios.
So, with FOB Point Source,
Advances are definitely a common theme.
We've heard this from many agencies
as a common business case, where they have to have Advances,
and they have to communicate the liquidation of the Advance.
So, the Delivered/Performed transaction
is going to be used in Advance situations.
Going back to what I said earlier,
if you have an Advance line schedule at the order,
at that point the seller can submit
an Advance Performance type
to collect the money from the buyer.
So, that's when funds settlement's going to be initiated
with advance payments.
As soon as I submit one within an Advance Performance type,
fund settlement's going to be creating
a flow back to G-Invoicing.
Okay, so what happens if I don't?
Let's say I'm a liar again, with Bill,
and say I've collected $100, and I say, boom, I'm done.
I want to get out of here.
I'm not doing any work for that.
I just collected whatever, how much money upstream from you.
So we have rules in place to prevent that,
and you can't close the order until you Delivered/Performed
all the way up to the Advance method you've collected.
So, the user, or the system potentially,
could be where the seller side of the transaction
will submit a Delivered/Performed transaction
to communicate the liquidation.
So an example would be I've collected $100
from Bill through a $100 Advance Performance type.
To communicate the liquidation of the Advance,
maybe I've delivered 50 of those items, those units.
I will submit a Delivered/Performed transaction of 50,
that's going to communicate that liquidation of the Advance,
so there's still 50 left.
So that's out of balance.
That order cannot be closed until either I minus
the Advance down to make it okay,
I collected too much up front.
I only needed to deliver 50, so we're good,
or maybe I just delivered half up front,
and I still have to deliver another half of the units,
so I can submit another transaction with Delivered/Performed
to communicate the rest of the liquidation of the accrual.
So Delivered/Performed is used in Advance situations,
and then Deferred Payment performance transaction type
will be used in document work in progress,
and agencies again, if I defer payment to Bill and say,
hey, I've done a $100 job for you,
but I'm not collecting that until at a later date,
whenever that is.
So, Delivered/Performed would then be used
an FOB Point Source to collect that money
that I did not collect for up front.
So this is when the seller goes in and collects the money
from this from the buyer, because the Deferred Payment
did not initiate fund settlement.
Again, that's through the Delivered/Performed transaction.
So the Delivered/Performed is very, very critical.
An FOB Point Source is used in every situation,
and you'll see that, I think literally all the time.
So, that's gonna be a common theme that we see.
Okay, so slide 10.
I'm not gonna walk through this in great detail.
This really just kind of captures what I've said
in a clearer picture, or in a better format.
So the five different scenarios that we have down the side,
are the Advance, the normal collection,
and again, FOB Point Source, your Deferred Billing,
your Adjustment Non-Advance, your Adjustment Advance.
Okay, there's the different scenarios that we have.
As you work from step one, to step two, to step three,
this shows you which trading partner,
whether that be the buyer or the seller,
and what performance transaction types
would be used for these different scenarios.
So I'm not gonna spend a lot of time.
We've already covered these with some examples,
but this really just shows in a better format,
in a table format, how these different scenarios are used,
and which performance types are used for each scenario,
and by which trading partner, which is very helpful.
Okay, so slide 11.
Let's talk about FOB Destination.
I spent a good portion now on FOB Source,
so FOB Destination.
This is a buyer's world, so this is what the buyers
would want to see, I think.
But again, the buyers may want this for every agreement.
The issue is you have to have approval
by your trading partner, so it's not up to G-Invoicing
at this point, we're not deciding which one you choose.
That's when you're settling in a GT&C,
you're settling an order.
You have to agree with your trading partner
what FOB Point you're using.
So this is agreed to at the order,
just as it was at FOB Source,
but the key thing with the destination is
the buyer has control of
when initiation fund settlements occurs.
So, in FOB source you have the Delivered/Performed initiated
from the seller, and FOB Destination
you have Received/Accepted initiating
the fund collection as the buyer.
You're using different performance types,
and really the thing is, when does the settlement occur?
So, this is when you get into Constructive Receipt days.
So we've heard from agencies,
well what happens if we have FOB Destination,
and the buyer never submits anything.
We'll never receive payment because it's FOB Destination.
Nothing is going to initiate an IPAC transaction.
So what we have put in place in G-Invoicing
is a thing called Constructive Receipt days,
which is almost like an auto approval,
but I am hesitant to use word approval,
because you don't approve performance.
So, what would happen is, if I submit,
it's FOB Destination on the seller.
I've delivered Bill 100 units, okay.
So nothing is initiating settlement at this point,
because FOB Destination.
If we agreed to 30 days, for example, on the order.
That's every performance would have, Bill as the buyer
would have 30 days to review, up to 30 days
before the G-Invoicing system is going to take action,
and submit a performance transaction on behalf for Bill.
Okay, so the Constructive Receipt date is critical.
You have to agree with your trading partner,
and if he doesn't submit a Received/Accepted file
by N number of days, by what you agreed upon at the order,
we're gonna create that for you.
So if he submits a Received/Accepted of 100,
because he's received all of what I delivered in five days,
that performance transaction
is going to initiate fund settlement
because he submitted his Received/Accepted file
with FOB destination.
So, Received/Accepted, that performance type
is not required for FOB Source.
I've already ran through a scenario with that.
What I mean by that is if it's FOB Source,
I've Delivered/Performed something.
If he agrees with what I Delivered/Performed,
he doesn't have to do anything
because I've already initiated funds settlement.
So it's not required an FOB Source,
unless you want to document some kind of discrepancy
that you want to see on that difference report,
and it's not also not required
if you have an Advance Payment indicator selected as Yes,
because what would happen is the seller submits
an Advance Payment transaction type
for the performance transaction,
and then he'll communicate that liquidation of the Advance
through Delivered/Performed.
So the seller can simply, same as FOB Source,
if you want to use Received/Accepted
to document the difference, that's fine.
If you received less than what you were delivered,
you should document that in G-Invoicing,
but you're not required to if you received
what was delivered, so just keep that in mind as well.
All right, so slide 12 is the FOB Destination chart.
We won't go through this again, but Advance,
and then in this situation FOB Destination
is really a push from the buyer.
You have Deferred Billing,
you have the Adjustment Non-Advanced,
the Adjustment Advance, and then each step
as to which trading partner would initiate,
or which trading partner would be able to use
a performance type, all the way through to the end.
So, we've covered some of these scenarios before,
but I think this table is very helpful.
It is especially for me to kind of keep track
of what performance types are really used
with each performance scenario.
Okay, so 13.
I want to kinda hurry to get Bill some time,
but slide 13 talks about adjustments.
So, when I say adjustments, we're not meaning chargebacks.
That word is not my favorite word, to use chargebacks.
We hear that often, so we had the IPAC awards today,
we talked about IPAC chargebacks,
we talked about all this information.
So, the issue is there's simply gonna be mistakes made
in G-Invoicing, so we have to have
the ability to correct these.
I mean, it's simply got to be built into the system
to be able to handle these requests.
So, an example of an adjustment would be
FOB Point Source on the seller.
I deliver Bill 100 units.
IPAC has been created, because it's FOB Source.
Delivered/Performed has kicked off that initiation, okay.
He only received half.
I'm a liar again.
I love that this is a common theme.
So he only receives half, so he needs to document
he's received and accepted 50.
Okay, so what could happen is,
maybe I only needed to deliver 50,
but I documented the wrong amount.
I could simply have made an error, an entry and say,
I've delivered too much.
I should have only delivered half,
or written down I've delivered half
of what I actually did originally.
So, at that point, I can adjust
that original Delivered/Performed transaction down
by referencing that original 100 unit
performance transaction, and doing a negative entry, okay.
So the key takeaway with adjustments.
You do adjustments by negative values,
and you have to reference
an original performance transaction.
You can't simply submit a new performance transaction
with a negative amount.
That's not gonna work.
You have to reference something you want to adjust
with a negative balance.
So that's really the key piece
of adjustments, we allow that.
Also, the other piece that's really important
with adjustments is just like FOB Point Source,
and FOB Destination, whichever one is chosen,
that trading partner is really responsible,
and that's going to be the side
that initiates fund settlement on the adjustment.
So we're not gonna have this back and forth,
adjusting, adjusting, adjusting,
that's gonna get out of control,
and, you know, you will never be able to settle
what you wanted to get done.
So what we're looking at is this is going to be
the mechanism, the FOB Point, to determine
which size adjustments initiates fund settlements.
So if it's FOB Point Source,
going back to my original example,
I submit that $100 performance, he received half.
Because it's FOB Point Source,
and I do a negative $50 entry,
that's going to initiate a negative $50 IPAC.
If Bill did a negative $50 entry,
that's going to not initiate fund settlement.
It's just going to make the differences
even further away than what they should be.
So just keep that in mind, adjustments, negative entry,
you must reference at a performance transaction,
and the seller is going to initiate funds settlement
with the adjustments if it's FOB Point Source.
The buyer is going to initiate fund settlement
on the adjustment if it's FOB Destination.
All right, so we've already covered this.
I'm gonna get through this piece
and give it over to Bill.
So, performance triggering settlement
is not available today.
It's gonna be available later this calendar year.
Release 3.0 is what we call that in G-Invoicing,
so if you hear that, that's what we're referring to,
the settlement piece.
It's also going to include the GT&C rewrite,
which is very important,
but that's a different conversation.
Also the settlement requests we pass
from G-Invoicing to IPAC, we have been building.
I guess FRB's been developing processes in G-Invoicing
to pick up the Performance, send it over to IPAC,
get that information back from IPAC
and update all the performance.
So that's current, ongoing.
We're almost finished with that work.
That's going to be deployed to Release 3.0.
Lastly, I'll let Bill cover the last piece there,
and then also the next couple slides.
Bill: Oh thanks Wes.
-: Yeah, sorry.
(audience laughing)
Bill: I got got two minutes.
(audience laughing)
-: You got more time.
-: Yeah, so we haven't announced the date
for the 3.0 Release, but I would expect it's gonna be
just after fiscal year end.
So, sometime in that time range.
We got a work around, there's an IPAC release too,
and we don't like to release IPAC around
the fiscal year end, so we're kind of
dancing around that on the border.
The last part there, the information,
we've just developed a software,
and so we're doing final testing now.
The information comes back from IPAC.
We'll find out about what IPAC calls the Accomplished Date.
We actually call it the Transfer Date.
It's a standard Treasury term,
and then we'll grab that do-symbol,
and a digraph dom back from there,
and that information will be pulled into G-Invoicing,
so if you hit the next slide there Wes.
Right now, when you when you're done today,
submitting your IPACs, whether that be bulk,
or whether it be online,
you're probably running a Transaction Download Report.
That's probably how you do your reconciliation,
and figure out who do we pay, or who do we collect from,
and you can continue to do that.
We are trying to, we did our best to try to map data
out of the G-Invoicing system into IPAC.
It wasn't a perfect knit.
We had to do some translation.
We had to do some truncation,
and we're trying not to expand IPAC.
We're trying to not do anything new with IPAC.
So, we hope that you're gonna wean yourself
away from the IPAC Transaction Download Report,
in the future as you transition to using G-Invoicing.
So the next three options, there are two, three, and four,
or how you gonna get data, settlement data information
coming out of G-Invoicing.
We're calling this Remittance data.
These are things that have been paid
from the buyer to the seller.
We will have the API I think Wes mentioned before,
the performance FIDS now includes that settlement data.
There's already an API out there where you can go
and pull that data, or your system can pull that data down
if you're using a vendor, if you're using Oracle, or SAP,
or Momentum, they're developing enhancements
to go ahead and pull that information to their system.
That will include settlement.
Once it's in your system, you know, SAP, Oracle, Momentum,
whoever, could could pull that data together
in a coherent way for you.
But we know that we're gonna have some online users
that people aren't using those systems.
So we're gonna have to pull that data together for them.
So the last two options, three and four are,
how could you get this Remittance package
out of G-Invoicing?
So, the first way is as a human user to go in,
login and export a CSV file,
save it to upload it into Excel,
and that'll include, that Remittance package
is gonna include about 110 data elements best we can see.
It's gonna be just a smattering of things from the GT&C.
There'll be lots of things from the orders,
and it'll be quite a bit from almost the entire
performance transaction and that settlement data,
and we'll put that together.
That's six layers deep.
There's lots of layers of that,
so it'll look a little bit ugly in Excel.
There would be a lot of repeated stuff on the left,
and a lot of, it will sum up well,
but it'll be maybe not the prettiest thing in Excel.
We're also going to put data, at a fourth format,
as an XML format.
That will be layered.
That will be what your system,
if you're pulling this data from using your system,
you can come in and pull off a month.
I'm going to pull August Remittance,
and it'll be a full package of all that.
It'll be similar to the data, you're getting it
from the IPAC Transaction Download Report,
but in in the newer G-Invoicing FIDS terms.
That's what you're gonna be doing from now on,
and as you go through this transition period,
you're gonna be having to pull a little bit of each,
and it'll be a little bit painful.
Keith mentioned pain a lot of times,
and it's hard work, but this is not a big bang approach,
and so you're gonna have to be pulling
a little bit of data out of IPAC,
and then a little bit of data out of G-Invoicing,
as your partners start moving into G-Invoicing.
Next one, so just wanna mention we do have
a lot of good good resources on the website.
Wes mentioned this the specs a little bit,
the System Interface Specs
where all these different rules are.
That's what the vendors are using
to to develop your solutions.
I'd also say that the Federal Intergovernmental
Data Standards, I think we're in a process
of republishing that, so the Order FIDS,
and the Performance FIDS now have a new column in them.
We're trying to designate which of these data elements
we want to put in the Remittance file.
We don't want to put everything in the Remittance file
because it gets to be too onerous and big,
and we don't want large text fields
that aren't gonna be useful.
So, I think we've earmarked about 110 data elements
that are gonna go in there.
It's about 4000 bytes long each now,
for each settlement detail.
We don't want to make that a lot bigger,
because then we might have to start restricting
how much you can pull out, and we want to make sure
that you can pull out a month at a time.
I think GSA was, I saw somebody here
they've got the biggest file,
and if they compress their file, we can get it down to
I think it's around 20 megabytes.
That's a lot of data to be pulling out.
So, most of the agency, the average agency
was much, much smaller than that.
So, just to keep that in mind.
So I think we're at a wrap time, and I want to thank you
for my three minutes of fame, and your attention.