>> Alright we're going to
go ahead and get started.
Welcome back everyone.
So, we wanted to -- our next topic,
or area of discussion that we wanted
to get into is broker interaction.
So, you know obviously the brokers are --
and I would add into that software developers
as appropriate -- we're key components to
getting the Alpha Pilot up and running.
So, we've got some questions here, some topics
to just sort of kick around and I mean just sort
of open it up for our understanding
a little bit from the importers.
How did you get the information to the brokers?
And I guess we're talking about
here the reference number primarily.
How was that transmitted and how, I guess,
did you align it with incoming entries?
Give us a little bit of background on that.
>>This is Bob from FNT.
We tied it to our Style Master files.
So, when we created the import we actually
kick off a common delimited file that was EDIed
over to the broker with the
registration number on it.
>> We did two different ways of transmitting
the information were not EDI connected
to our border broker.
So, what we did is we gave them the LPCO code
with a product database and they programmed
that into their article product library and
used that every time we made a shipment.
So, that was the manual process.
99 percent of our business
though is EDI with the broker
and we do tie it to our product master file.
So, within our product master all the
information we use a series of flags
to flag the article as subject to the CPSC
pilot and from there that kicks up a series
of Bischman's [phonetic] Logic to go out and
pick up the GCOC full message set and then
that gets incorporated into our XML to the
broker, who then puts it into the catare.
[phonetic]
>> From a Walmart perspective;
we have EDI transmissions set
up with our brokers for purchase order data.
We don't have specific product data
that they call through and pull.
We push them specific purchase order
data depending on the clearance port.
So, we couldn't necessarily tie
the registry number to an EDI feed.
What we had to do was we had to take
what Kara [assumed spelling] had entered,
run reports to identify which purchase
orders those products were attached to,
and send the broker -- via
an Excel spreadsheet --
a complete listing of purchase orders that that
registry number would apply to for those two --
for the two ports that we were working with.
So, it was manual.
>> Sounds like a very manual process.
>> Very manual.
>> Yeah.
>> For Fruit of the Loom it
was also a manual process.
We provided spreadsheets for both
our whole message set data as well
as our reference certificate numbers to the
broker matched up with the correct product ID
and they added it to their
internal product library.
>> So, I'm hearing that if it's not
an EDI it was a two file transfer
where the broker then had to
join based off of the filing.
Okay.
>> For Proctor and Gamble we
also followed the manual process.
We separated our normal process of
information for this pilot specifically
because we were very limit -- we
were limited our participation
to a particular supplier import and --
but we simply added the reference number to our
product data master files for that supplier.
And with the anticipation that it will
eventually become an electronic process once all
the data elements are finalized.
>> This is Garrett with Seventh Avenue.
Ours was pretty simple.
We basically just tagged a reference number
onto the end of our EDI feed to the broker
and that related to our complete products
database that we transferred to them.
>> Okay, from the broker's perspective;
what were some of the issues
or challenges that were faced?
You know I know we had heard about some
issues and we knew there were some delays
from getting the code from the
vendors -- software vendors --
and getting that code tested and implemented.
So, you know some of the challenges that sort
of the brokers faced and perhaps even some
of the challenges as it related to
their interaction with software vendors.
We'd love to get some more information on that.
>> Hi. This is Ian Smith from Expeditors and
we actually did not have a lot of trouble.
For one thing we are a self-programmer.
So, we program all our ABI software.
And we opted for the -- just the simple
transmission of the registry number.
So, that was quite simple, quite easy
to get up and running pretty quickly.
We -- you know we could have done the full data
message set, but it just made much more sense
to go with the simple transmission of the
registry number, which was pretty easy to get.
It was very simple to get from our importers.
And from a technical standpoint
I don't know if anyone
from our Seattle -- from
corporate's on the phone.
I think everything went just fine.
>> To add to what you said, Ian, from our
perspective, because Expeditors was our broker
of choice for the pilot, what I --
the feedback I got from them was that,
you know as long as they had the data they
could supply the data and that was fine.
However there was a disconnect
between what we had --
has been indicated on the survey in terms of the
message -- the total -- verses what they filed.
So, they stated they filed
140 entries on our behalf.
We have 121 message sets.
Their thought process was that there was
a potential for disconnect between CBP
and CPSC via the Ace transitions.
So, something maybe you want to check.
[inaudible background comment] Yeah.
Their entries were 105, lines were 140 for us.
>> And they said there was 120?
>> 121 was listed and 136 on the survey.
>> Sorry. Okay.
>> So, just something to --
>> Well, it'll be interesting to
see what -- where the drop off was.
>> Yeah. Just something to check.
If we could -- I mean if they
have that good of data --
if we could get it from them with
the entry numbers and entry line.
>> We can work with you to try
to figure out where that drops.
>> That would be great.
We can absolutely look into that.
Yeah. But other than that, you know they
didn't have any problem, as Ian had indicated.
>> And Expeditors again, you
only programmed to be able
to transmit just the reference number, correct?
>> Yes Jim, that's correct.
>> Okay.
>> So, I think Jodus [phonetic] if you're
on the line, you also programmed to be able
to file the full PGA message set.
Can you give us a little
background on that process?
>> Sure. We actually use an
outside software provider.
We don't do our own programming.
So, our software provider
did do that programming
for both the full message set and the registry.
We actually do have two separate
applications for ABI.
This is Chris, I can speak on one.
Maybe I'll have [inaudible] speak on the other.
So, for the one; everything
went fairly smoothly.
I think our biggest challenge was in adding the
CPSC information to our internal products file.
We had to kind of quickly come up with a way of
doing that, which long-term probably won't work.
So, we'll need a better method of doing that
with a larger pilot or the actual go live.
But overall I think everything
went fairly smoothly.
I think the registry was definitely
the easier way to go and we would want
to encourage our importers to use that
as the preferred method if possible.
So, the easiest -- the easier
that is for importers
to use I think that's going to be the better.
If Jennifer you're on the line maybe you can
speak about our other system and how it went.
>> Sure. Well, I can't really add much except
the fact that I know that one of the challenges
that our software provider was facing at that
time was some of the other changes they had
to make with -- there is some limitations.
So, certain things just had --
were put in a different priority,
but once we did get the programming
in place and we tested it we were able
to send them through successfully.
>> Ace implementation was interesting and, you
know I think we had this as sort of bullet point
on the next side with filing, but
you know the -- as you all know --
the Ace schedule slid and we were hoping
to hit sort of a sweet spot in there
between Ace implementation and other things,
but it ended up that we got really stuck right
in the middle of prime I guess
programming time for Ace.
So, we do recognize that there were higher
priorities with mandatory Ace transition
that we came -- we bumped up
against and I think we lost [laughs]
out on the priority a number of times.
So -- but yeah we do recognize that.
Did you have -- ?
>> Yeah, Jodus filed for us so -- at FNT --
and of the 27, you know products we did --
359 line entries, 342 CPSC message
sets -- I think everything went okay.
I do know they had challenges, you know
setting up some of the programming,
you know with the Ace challenges, like
you just mentioned, and long with,
I think some of the challenges
with the transmissions,
but once they got past that it worked fine.
>> Yeah, I would echo.
Jodus was the one that filed our --
except for the Laredo Board of Brokers
is what filed for us, in Laredo.
The programming Ace definitely contributed
to some of the delays in that they had
to dedicate their resources for some of
the Ace implementation that was mandated.
[laughs] So, it did push it a little bit.
I think one of the other things that we
struggled a little bit -- and Jodus --
is that initially they had programmed to file
at the 7501, which is the standard trigger
for CPSE filing on the summary, and when they
went to program the error messages coming back,
or the accept messages, didn't
make a lot of sense,
according to the 7501 or the summary filing.
So, we switched to the 3461.
I think that piece also caused a couple of
delays into when we should have been filing
because of the 10 day delay -- or the nine
day delay -- between the 3461 and the 7501.
So, that was the other issue that we saw.
>> So, you were getting errors when you tried
to attach it to the 7501, but not the 3461?
>> Correct.
And then when we got the acceptance messages,
against the 7501, they didn't make sense
because they're really designed, I think, to
attach to the release, which is an indication
of hold authority rather than
just contributing information.
>> Got you.
>> So, I think you're all familiar with -- so
CPSC had you know we had put together with --
working with CDP and in review of
the Trade Support Network our catare,
our implementation guide.
You know I guess just sort
of a general question about,
you know how -- any comments on that guide?
And I guess in particular, looking for sort
of any feedback on anything for the future
that we could do better as far
as interacting with the trade,
I would include brokers and importers.
You know if we're able to move to a Beta
phase; what could we do better as it relates
to communication, documentation, anything
that would help the process smoother?
For example; with companies that might
join, that are brand new to this?
>> I have a thing that could
relate to this issue
and the previous issues that
we haven't discussed.
Sorry, I should have said [inaudible].
I don't know if any one of the others
have been thinking about the disclaimers,
meaning that we will have a flag on certain
custom [inaudible] that we need filing.
But the product requirement definitions
and the custom codes don't
quite really match up perfectly.
So, we will -- there will be a need
for disclaimers and for us internally
that seems a more difficult situation to
handle because it's a non-requirement.
We are clear -- we know exactly which product
we should have a certificate of compliance on.
The question is; how do we identify correctly
which products that shouldn't have a certificate
of compliance and should
have a disclaimer instead?
I don't know if any other companies
have been thinking about this.
>> This is Jennifer from Walmart.
We have been thinking about it.
Not necessarily from a CPSC perspective, but you
know Fish and Wildlife is another good example
of that, where the disclaim
process is potentially burdensome
because you essentially have to -- it's not
a yes/no anymore it's a "No, but here's why."
>> Right.
>> Yeah.
>> And sometimes that's more
information gathering
than you have already with a yes answer.
>> Yeah.
>> And you have to maintain records associated
with that where in the past you didn't.
So, yeah we have thought about it.
It's not something we've necessarily addressed
yet, but you know it is a good issue to talk to.
>> Yeah, and that's -- it is an issue for
us that we definitely need to think more
about as well, just this sort
of the nature of the HTS.
You know there are some codes
-- toys for example --
are a lot more straightforward
and I would expect less disclaims,
but when you get into some of the apparel,
disclaims can be -- [clears throat] excuse me --
a really big issue and how do you address that
so that, you know again trying to get back
to minimizing the burden and not having
to spend a ton of time disclaiming.
So --
>> I think, to add to that, two
things; one is that it may be subject
to CPSC, but no testing required.
Is that disclaim or is that a GCOC?
And then the second would be; there are
some items that have a tendency to be
in the gray area that you wouldn't
necessarily flag the HTS for,
but they're probably still subject to CPSC
and how are those, you know accommodated?
>> The general process and vision
across the jurisdiction for CPSC --
just from a very high level -- if there's
no certificate expected you won't have to --
the HTS will not even be on the
list, we won't even be looking.
If there's, you know below a
certain percent threshold on it --
proportion on a certain HTS --
there's going to be a lot of burden
because it's going to be a majority disclaim.
You know how much are we going to -- ?
I mean this is an initial thought
as we're digging through this.
Above a certain threshold percentage, let's say
70 percent or 80 percent of the HTS is expected
to apply, you know in that situation then,
you know those exemptions are expected to be
on there and it's worth the burden,
potentially, in that type of an instance.
The fine line is going to be
those HTS codes, where it's,
you know the Toy 90 Code, the above 12.
You know how many of those are going
to really be ones that we're watching?
You know imitation jewelry.
Those are another -- those are
questions that you just have to say,
"Do these really -- what's the proportion?
What's the burden verses the -- ?"
And that's something that
-- it's a hard one for us.
>> Yeah.
>> It's definitely a hard one for us.
I mean -- and we identified that early on.
>> If it's a burden or if it's hard for
you to -- also it's hard for us as well.
So, we're trying to second guess what we
think you might be needing or wanting.
So, maybe some clarity around
that would be great.
>> Right. Yeah, I think that is
definitely an area we need to work on.
>> Well, I think as Jim said
a little bit earlier,
the Alpha pilot was really broad
intentionally because we were trying to get,
you know volunteers with
whatever products they wanted.
One of the things we are looking at and thinking
through with regard to the Beta is what makes
since and we're not necessarily think it's
going to be this kind of free for all,
but more "How do we prioritize what
we're looking for, not only to help CPSC,
but to help the people who sign up
and who want to come on board to say,
'let's make this make sense
and be logical and be --
what's really important?'" And also
just to give you more guidance.
>> One other thing to consider too is that,
you know the Beta pilot -- or I'm sorry --
the Alpha pilot was pretty straightforward in
the tariff classifications that were being used.
You know essentially it's called for in
the tariff, it's a GRI one in most cases.
So, it's easy to recognize, easy
to flag, easy to say yes to.
But further to her point, if you have
embedded items in a kit that are subject
to a CPSC requirement, but the nature of the
kit itself isn't a toy, then you have to be --
we have to be able to account for
that testing on that particular item,
but how do we declare it at entry?
Because the primary tariff
code, the way we do it, is XVV.
The X line is going to be declared, the V
lines are going to be supportive and there,
but not necessarily seen by your side.
So, those are the kinds of things that you're --
that need to be considered as well as you move
down the level of -- as the level
of classification gets more
complicated from GRO and [inaudible]
>> Right. And in terms of kits one
of the -- this is John from CPSA --
in terms of kits I do know
there's a nuance within the UPCG10
that supports the identification
in the GPC of kits,
and specifically bundled
beyond a classification,
which is one of the reasons why that's
so attractive is that if it's a kit
within a certain classification
that's something that we're going
to be potentially interested in,
if it's a kit that's outside.
And so it's identified as a kit and we
know that there's going to be elements
and we -- that's something HGCS can't do.
In some instances the products are
supposed to be declared separately
and in other instances they're not.
And you know that nuance is a tariff
issue in terms of how they break that out,
but it's not a character --
product characterization issue.
And so it's hard for us to
get that standard policy.
>> I understand that, but
for us it's going to have
to be an exception management
that we have to account for.
So, that will be difficult
to automate personally.
>> Agreed.
>> So --
>> We are very sensitive to the
exception issue and we've --
from the very beginning as we've
been looking at the overall products
of risk -- how does that get managed?
That's something that's been on --
>> Right.
>> And I think a lot of it goes
back to sort of looking forward --
is how we defined scope and what are
those tariff numbers, product types,
that we are really interested in?
What's the data that we need to
be able to do import targeting?
You get -- I mean it can -- you
can get into the weeds very quickly
and it can get very complicated when you start
getting into kits and jurisdictional issues.
You know we do our work based on a
feed of data that we get from CBP
and that's defined by tariff number.
So, it's how does all of that mix together?
It definitely is a very complicated issue.
>> If all the HTS codes were as clear as toys
under three, life would be wonderful, but I --
we're going to have to nuance this together.
So --
>> All right, I've been told
it's a good time to move on.
[laughter] So -- and again I
know and we've talked about --
I know there's just sort of overlap with all of
this, so you know feel free if you have comments
on some previous issues that we've talked
about, feel free to come back to them.
I mean we are -- we want to make this sort of
as informal and conversational as possible.
But sort of the next topic
that we had is around filing.
And you know I sort of hit
on this a little bit about,
you know sort -- of what could we do better?
But you know sort of thinking
about filing, what could be --
any suggestions on how we could
do this in a way that is --
that puts the least burden on industry?
Again, you know sort of this is a tradeoff
here in the sense that we're trying to get data
that is going to help us do our
job better and as part of that,
better means that we don't stop
shipments unnecessarily, you know?
We can identify those risky shipments
based on the data that we have.
So, part of this is we do feel a
trade facilitation aspect in that
if we get the additional data
we know what not to look at.
But with that in mind, sort of
thoughts on, you know how can we --
how could this be set up in a way that sort of
sets out the least amount of burden on industry?
Any thoughts would be welcomed to hear.
>> This is Ken [assumed spelling] from Walmart.
I think we just have to be very
selective about the data that's required.
I mean at the end of the day whether it's
automated or manual or some combination thereof,
the more fields that are required, the more
tariff codes that are required, on and on,
it's more work, you know regardless
of what that system looks like.
And so I think we really need to understand
-- find that sweet spot between --
and I know you're working to do this.
I'm not telling you anything you don't know, but
we really have to find that sweet spot between;
what is the burden -- Because
the burden can be significant --
verses what is the utility of the data?
And so, you know I think that we need to
continue to have that conversation is;
what is it that the CPSC is
really looking to get out of this?
And what is that smallest universe of data
that trade can provide to
you to accomplish that goal?
And let's see if we can find
a way to settle there.
You know I'm worried that you know it
-- you know we'll take one step forward
and then we're take another step
forward and then a little bit more data,
and then a little bit more data, and
then all of a sudden we're overwhelmed
and we're providing just, you know
millions of lines of data to the CPSC
and really you're utilizing, you know
maybe a fraction of a percent of that.
And not even be designed that way, we just
kind of find ourselves there before we know it.
And so I think we just need to be really
disciplined about; what do you need?
How can we provide that to you, you
know in the least burdensome way?
>> Yeah, I agree 100 percent.
The Chairman in his opening
remarks, I think he used the phrase
that the Alpha pilot was testing the
plumbing and that really is what it was.
I mean we set up the structure, right?
We set up the process and the volunteers
and the brokers really helped us
in testing that to see if it worked.
The Beta has always been envisioned
by staff -- is testing the elements.
How does the data itself
help us to do our job better?
And I think that's where we get
into the conversation about;
are those the right five pieces of information?
In the end is it less that we need?
Is it more?
I don't know.
-- I mean I'd have to think that it's going
to be hard for us to say that we need more
when we're not testing other data elements,
but you know the commission I think was --
really listened to the feedback from trade, as
we were discussing E filing at the beginning,
to try to come up with; what were those data
elements that we think would enhance the risk?
And that's where the Beta is really
hoping to go is to test that data to find
out whether it is in fact
the right data elements.
>> And I'll just give you my
first concern around the Beta --
and this is one of the reasons in our
responses back to you we didn't fully commit
to participating -- because my concern is
that in order for you to obtain the amount
of data you need to really test
what's useful and what's not,
it's going to require either an
enormous manual lift on our part,
or it is going to require some
sort of systems development.
And until we know what that system is going to
look like long-term, that's not an investment
that I can go to my bosses and say we need
to make because as soon as we make that
and we finish the Beta pilot
we're going to say, "Oh,
well actually the system would work better --
now that we've had, you know 200 participants,"
or whatever it is, "the system
should actually look like this."
And then we're going to throw
our money out the window.
So, I'm not sure how we're going to balance
the need for you all to acquire a lot more data
from all your participants verses the
need for us to have some sort of finality
around what the automated process looks like
before we start developing towards that.
So, I'd almost say I think we need
to maybe focus on that systems piece,
that automated piece, figure out what that looks
like, before we move to the massive amounts
of data to determine what is really beneficial.
>> Currently the CPSC is directly
sharing information with CVP to be able
to assist our process out of the ports.
Jurisdictionally we're talking about some 90
odd million records a year that are being passed
so that we can understand what's going on.
The volume of information there is -- it's huge.
It's absolutely huge and the process that
we've got established with CVP is one
that was mandated under the Safe
Ports Act that we needed to --
and participation in ITDS that we get this done.
The standard set up there is, you know
is something that could easily apply
to the other -- we don't want to have
multiple different tools as well.
I mean we have limited staff as well as you now.
And so we can definitely take the lessons
learned from that and apply it back out.
The technology piece is something that we can
definitely work with you all and I do believe,
in terms of developing some technological
standard, is something that's not going
to be a hard lift in terms of proposing out.
So, I mean that's something
that we can work through.
We can definitely work through.
And we're doing it right now and the
agency has standard exchange going.
So, it's, you know in terms of
cost we'll work through that.
I mean you know where I'm headed.
So --
>> I was just going to say, you know I think
the line or sort of the objective in --
because I agree with you on
the technology part of it --
is getting that to be as easy as
possible to transmit the information.
I guess it's also having it be flexible
that if in the end, say CPSC determines
that we don't need five elements, we need
three, that the technology can change and not --
without incurring a tremendous amount of cost so
that it can be flexible enough to change that.
>> In that type of an instance
you'd have the same hardware
and you'd probably have the
same general programming.
It's just that what you're going to be
doing is -- your XML layout would change.
The difficulty would be -- we as an agency
don't want to have individualized feeds
from each company, that would
just be ridiculous.
We don't have enough staff to be
able to do that kind of thing.
So, I mean just envision it's going to be a
standard technology, like an SFTP type drop
and process, EDI exchange, where
on a periodic basis we would say,
"Okay, this data's not working for us.
We're going to drop these.
Let's maybe add this one element."
There's no way that, in my mind, beyond
five, six, seven data elements are ever going
to be useful to the agency just because
of the nature of what we're trying to do.
It's product risk, it's entity
risk, it's location risk.
You know it's not -- there aren't that many
elements that we need to be able to turn this.
So, that's my view at this point.
>> I think I just want to
say, you know all good points,
but to what you said specifically
can -- we do hear you.
When we sit around talking about what this
Beta looks like our question is; what do --
how do we design this so people will actually
participate and that it both makes sense
in the short-term and is leading to something
that CPSC can get behind long-term and be able
to tell trade and the importers
and the industry,
"This is something we're
getting behind long term."
And whether that's minimizing HTS codes based on
what we feel we really will need, will look at,
will use to help indicate what we
want to look at and what we don't.
We're looking at a lot of different ways
to try and make sure that what we're asking
for is what we're actually going to use
and that we're not -- to your point --
just collecting data to collect data.
And that is a huge part of what we're working
through with this report that we're putting up
and with how we're putting in
options for what the Beta looks like.
>> Yeah, under Beta -- I mean the hope is
that -- and we have to work this through,
but the information would then be directly
tied into the system that we're using
out at the borders and be able to flag folks
to differentiate the product and be able
to demonstrate that and to
show how, you know the scoring
and the overall methodology would be
significantly impacted within that structure
on a larger set of data that's coming through.
The one off collection that we
did, you know we didn't integrate.
So, that's something that we could -- you
know we're going to be working towards.
So --
>> I know we have a message
here about warning messages --
or a question here -- about warning messages.
And I think there was a little discussion,
but sort of any other feedback information
about any warning messages that you received?
And I guess were they instructive
as to what the issue was?
Any thoughts on how they could -- how they
might be able to be made better moving forward
so that they are better instructive
of the issues?
>> I think most of the issues we
had during testing were resolved.
There were a few of them that were
unclear that we had to go back
and say, "Not sure what this means."
I think there were a few of
them that Jodus encountered
that we had to work with CPSC to clear up.
It was on the CPSC side.
And if we're timing that
with the one USG released
through Ace, I think that's even better.
So, that it -- conceptually importers
know that CPSC is part of the one USG.
>> Just I guess before we move
on, just any other last thoughts?
Comments on filing?
>> Well, [inaudible].
One thought there is; when we go
further we're going to [inaudible].
As soon as possible we'd need to know
if we're going to have the same elements
or if it's [inaudible] other to
be able to prepare in a good way.
And that applies also to when
it's time for the real thing.
It's very good if we know in [inaudible] exactly
what type of data and structure it should have
because once it's real we cannot say
to CPC, or to anyone else, "I'm sorry.
We cannot -- we don't want
to participate anymore."
So, we would need to have everything in
order and everything as it should be.
>> Understood.
Yeah.
>> That takes some time.
It takes time.
>> And I think to add on to what
Magnus is -- I absolutely agree.
It's quite easy to add information
to an XML to transmit data.
But thinking through that process, while
it's quite easy to add something to an XML,
it requires mapping on somebody else's side
to receive it in, to put it some place,
and to map it back out through Ace.
The other thing is, when we add a data element
we all have to go back into our source systems
and say, "Where do I get that from?
How do I interface it in good way
to our entry data so that it flows
through without a lot of manual intervention?"
And I think that's where Magnus is
coming from is that when you think about,
"I just need an extra data element."
Think about really the timing that it might
take to add that data element and what each
and every one of us will have to go through
to ensure that you obtain what you need.
>> Yeah I think -- [inaudible] Go ahead Magnus.
>> Yeah, just to give you
once more -- like [inaudible].
Someone changed a bracket in the feed
and the whole information flow stopped.
[laughs]
>> Yeah.
>> And that could also happen
if you add something new.
You don't know exactly how everything will
behave until you have really tested it through.
>> Right.
>> And that is something we want to do in very
good time before we [inaudible] in something
and also preferably the same
thing for the data pilot.
Or the Beta pilot.
>> Right and I think, you know the staff sort
of that has been working on this that is,
you know certainly something as far as scope
that we have our eye on in order to be able
to provide some options to the commission.
And I think the two big areas of scope are
-- scope as far as it relates to products,
HTS codes -- that would be in the Beta and
then scope as it relates to data elements
and what data we would be looking for.
Again I would just say, you
know the Alpha was really set
up to test -- set up and test the process.
The elements themselves have not been
tested for their usefulness in targeting.
And so, you know just my own personal opinion is
I'd sort of expect them to remain the same going
into the Beta because I don't
think we have a basis
for really recommending changes at this point.
>> I had just one other technicality
that I wanted to add on the technical --
and it might be that we're
operating a foreign trade zone.
And I'm not sure if anybody has brought
up the use of a foreign trade zone
and when the most appropriate time, but what we
have found with other government agencies moving
into the PGA message set that seems
to be exceptionally problematic.
So, if there's an opportunity to think about
that and how you use it that would be fantastic.
>> We've met with foreign trade zones several
times and to understand the general process
and one that would be ideal, for example you've
got a standard weekly release that you're going
to be pulling out and when to declare
and when to get that information
through has been something that
we've been actively studying
as part of this overall process as well.
So, we're cognizant and we're willing to --
we'd actually love to have pilot participants
under the Beta who are going to give us
curve balls such as the FTZ issue, such as --
I'm only ever bringing paper
to the CVT desk, I'm --
you know these are the kind of things that under
a Beta you want to understand the full breadth
of the process to make sure that
you're addressing it as best
as you can before you turn
it on for full production.
And we really want to make sure that
we're getting a full understanding
for all the different processes and the nuances.
That we can share policy prior -- and discuss
policy -- prior to flipping that switch.
>> Yeah, we did meet with the NAE,
FTZ folks and they were great.
They came in and really laid
the foundation for educating us.
[laughs] FTZs are a complicated
-- it's a complicated process.
So -- but they were very helpful
and we did commit to continuing
to have dialogue with them to understand it.
They were -- we talked a
little bit about E filing.
They were, you know particularly interested
in certificates of compliance, which is --
you know this is all sort of mixed
up together, but -- so that --
so, yes we've had dialogue
with them and continue --
we probably will continue to have that.
>> All right, so we're going to move into our
last topic and it's really recommendations.
And you know we've touched on a
number of these things already,
but you know this is an opportunity to
just, you know give us your thoughts
on what can be improved as we move into a Beta.
We're always -- we're looking for that feedback.
We do really feel that we've had --
that from our perspective that this
has been a great situation in that,
you know we've really worked closely with some
really good importers and brokers to be able
to develop and test this process and
we want to keep that dialogue open.
We want to continue to try and learn from
you as far as your experts in what you do.
So, we want to try and learn from you as
far as, you know what is the best way -- ?
Again, striking that balance.
What's the best way to try to create the least
burden on industry while still allowing us
to get data that we hope is going to
make our job and what we do better.
So, you know with that I
would sort of open it up.
There's some -- you know some specific questions
here, you know improvements, moving into a Beta,
onboarding and communication, the
testing phase, the production phase,
post implementation, pilot timeline.
So, you know I'll just open it up and anything
that you all have we would
really welcome to hear.
>> So, first I think Ikea would
like to say thank you very much
to the CPSC [laughs] for doing the pilot.
Compared to other PGAs that have gone live
into the PGA message set this has been
very organized, it's been very pragmatic,
very open to questions, responses,
available to the community.
So, thank you very much.
We were very pleased with the onboarding,
the communication, the phase of the pilot.
It went quickly.
We didn't anticipate that it
would go as quickly as it did.
We were hoping we'd be ready at the beginning
instead of a little closer to the end.
[laughs] So, that kind of brought us
to the other areas that, for Ikea,
we felt that maybe the production
phase would be a little bit longer
so that we could really get a handle on
what we were seeing, what we weren't seeing,
where would we need to make modifications
or changes to enhance the process
or gain efficiencies while at the same time
getting you what you needed as an agency.
So, that was Ikea's feedback.
>> I do think on timing, you
know we were really hopeful.
We went live in July and we were really hopeful
that everyone would sort of be ready in July
and get sort of a full six months of filing.
Obviously that didn't work with everyone.
So, in the way that we had set this up with
CVP is we had sort of defined timelines
and we had put a federal registered
notice out with some specific timelines.
So, it really did kind of box
us in so to speak on scheduling.
I would say, you know sort of the
staff's view on the Beta is that the --
that that would be a pilot that would be
much longer from a data collection phase,
probably about a year's worth of data, or a
timing to file, because we would be looking
to be able to get that data to
determine its usefulness and sort
of have a much larger number
of importers participate.
So, we are thinking about a
longer implementation time there.
>> Yes. Definitely a broader
number of participants.
You all were the cream of the
crop and my expectation is that,
you know if we did integrate this with
targeting we would have not done anything.
So, the issue is that for us we would want to,
you know integrate it potentially with recalls
that are announced, be able to
integrate it with other process
that we have in the agency, spend that time.
It's going to take time to key all that up
and to process it through and then to deal
with all the different ways people file, all the
modes of entry where we're going to have issues,
and where this actually provides a different
benefit potentially at the sea environment
than maybe a land boarder,
give those kind of nuances.
And potentially the land boarder --
it might even be better depending on how
active our feed is, you know over time.
So, you know these are the
kind of questions and --
that a Beta would allow us to be able to
demonstrate a lot more benefit over time
and to really be able to provide
a much better set of procedures
to support everybody, not
just the cream of the crop.
So --
>> I have a question -- or a thought actually.
In terms of data validation on your side,
you know we are -- I think you heard --
we're entering, we're reviewing our
product, we're dedicated to doing that.
We're entering our product detail,
data requirements, into the registry.
Is there a way to establish a timing aspect in
terms of, you know a pass/fail kind of thing?
So, if you -- we as Walmart have entered in
3,300 products into the product registry,
within a certain amount of time,
or even a rolling amount of time,
as products are being entered and reviewed,
is there a way for your validation process
to identify a, "Yeah, we're
going to target this," or a, "No,
we're not going to target this,"
and notify us ahead of time --
or notify the trade ahead of time --
so that we can take care of it prior
to entry, whatever the issue may be?
>> That's a tough one in that obviously the
classification would need to line up to be able
to give us an indication
that the cargo is out there.
In terms if there were specific warning flags
on a manufacturer that you may have provided
that information on, or if
there's a known recall on a product
that you're providing us information on the
registry way in advance, and you weren't aware
of this, for a code, there might be
something that we could work on to do that.
But we've not -- we've got to bean this
process through with you as part of that Beta.
But it does not serve us at all in wanting
you to send through the process something
that we know that's going to be
recalled, that's going to be stopped.
We want to give you as much
advanced notice as possible for us
because it then provides us the ability to
not have to look at that product at import.
I want my people looking at other stuff
if you're already giving
me a warning ahead of time.
And in my systems I can do that ahead of time.
It would make sense.
How that works out, we'd
have to bean that through.
>> Yeah, it's interesting because
the way that we do risk analysis;
we do it at the line level basically.
So, that's where our rule
sets and our scoring kick in.
So, what -- if I understood your question -- I
think what you're looking at is for us to push
that risk assessment prior
to entry at the product level
and we'll have to think about that.
That's just not how we're set up now because
the way that our targeting system is set
up is we get this feed of data from
CVP on -- based on our jurisdiction,
then based on entry -- or based on
line -- we do our risk assessment.
Now this -- the E filing
data would be additional data
that would feed our rule set is the
way that we've always thought about it.
>> Right. And if it's coming in way in
advance and we've got something to tie it to,
we'd have to set up programming to match
that up, do the join, and provide some type
of notification, do some
research, and then reach out.
That's a new process for us.
>> Right.
>> That would be a new process.
But it's definitely in the
realm of what's doable.
>> Yeah. I mean I think it's definitely
something to consider because if you've heard --
as you've heard from everybody, they're
tying the registry to their product.
You know we're an anomaly in that way.
We then have to tie the registry of the
product to a purchase order to an entry.
So, if we can tie the registry to a
product, have that product reviewed, then,
you know obviously we can still assign a
registry number to that product for entry,
but if it's not tagged at entry then there's
not as much pressure from a timing perspective
to have everything on our side done and
completed, and reviewed, and renewed,
and reviewed, you know prior to entry.
So, I just think it's something
to try and consider.
It may also eliminate the need too to
justify a disclaim because if we've had
that product reviewed, we
know it's not subject to --
even though the tariffs say
it may be subject to --
then there's no need for us to
do a disclaim process against it.
>> I would argue that as our process
would mature, if you ever filed a disclaim
against a product code you would not
necessarily need to do it more than once
because we would develop a history file
that would state that this was a disclaim.
And potentially at that point we would then
know and not send you an error message saying
that that was ever a problem
with that code in the past.
I'm just thinking this through
with you out loud as part of this.
I'm not promising anything,
but this is the kind of --
these are the kind of processes
that as we develop this
over time that you can have those built.
>> Right. But you're thinking that from
the code level, not the product level?
>> I'm thinking that at the product level.
>> Okay.
>> If you disclaim at the product
level prior and it's been shipped in
and there's a verification -- maybe some type of
check box that might have been done that, "Yeah,
okay we didn't need a certificate on that --
," if I had that sitting somewhere I can match
that on any registry coming through and
then if you file it, it makes sense.
>> Right.
>> It's not built, but it definitely
makes -- the theory makes sense.
>> I think the theory does make sense
because just thinking about the information
that we're going -- that you get right
now -- that we've gotten in the registry,
it is a lot of those core pieces of
information that you would use for targeting.
You don't have the entry information.
You don't have the line information.
But you've got a lot of the key components.
It's just like John said, you know
we're just not built like that,
not to say that that's not a
good place to go at some point.
>> Right because when you
get right down to it it's
about the product, it's not about the tariff.
>> Right. Exactly.
Yeah, thank you for that.
>> I think [inaudible] consider those topics
and we consider that type of process though,
I think we have to consider the interface
with Ace and the interface through US Customs
and the brokerage, who may have programming tied
to saying, "This HSC number is subject to CPSC."
They may outright reject
it from an EBI standpoint.
You can't get it through
so I think we [inaudible]
>> Well -- right.
I want to clarify one thing in the
vision that we've seen longer term,
and this is from a staff
opinion at this point in time.
I don't think we'd ever have, within a certain
HTS code, CBP reject on our behalf in advance.
We would be sending signals from our
system to their system interacting.
There's not going to be much in the way of those
bucket one failures unless it's just typed badly
that they're going to say,
"You need to fix things."
But on our behalf, it's going to
come all the way back to our system.
Now, if there's a registry filing there's no
reason why we couldn't have our system talk
to your system potentially independent
of CBP, that's added expense,
that's added work, we'd have to figure that out.
Or, potentially Ace was originally
designed to try
to pass everybody's trade
documentations out and back through.
How well would they be able to support that?
We're still working with
CBP to test those as well.
So, in terms of that coordination of documents
-- filing documents directly through Ace.
So, yeah that's going to take some time.
We're working on that element as well.
>> This is Charles from Fruit of the Loom.
I've got a question; a lot of
our products may be subject
to the rules, but exempt from testing.
So, I mean you would expect all those products
to -- in the future, the Beta program --
to still be uploaded into the
registry or send the full message set?
>> Well, the way we had it set up, and I'll
ask Lisa if I don't get this right to jump in,
but I think the way that we had this -- had it
set up is we had the ability where it was --
where the testing -- where you could
identify the testing entity to be able
to indicate no testing was required.
But under the Alpha, yes we were asking
for that information to be filed.
Could we look at that as, you
know something to consider --
how to deal with that in the future --
certainly, but that's the way
that it was set up in the Alpha.
>> Under the PG message set when we
evaluated the full PG message set,
there's the line exemption and
then there's the test exemption.
The PG message set architecture on CBP's
perspective does have that capability.
It also has that capability to nest multiple
manufacturers within their architecture.
That being said, I don't think in this pilot
we went that route and in the Beta we want
to test more complicated designs.
So, you do have the ability to do test
level exemptions, you do have the ability
to do entry line -- this HTS is exempt --
So, yeah that's how we do it, how we test it.
We want to be able to get a little
more complicated under the Beta.
>> But just to clarify we -- if -- in that
situation Charles, we weren't expecting you
to put it in the registry and we weren't
expecting you to file the full PGA message set.
There was an alternative message set,
which we believe will move forward with --
where it's basically you declare the
exemption -- say, "I didn't need to test this."
So, it's not a full PGA message set, it's small,
kind of like the reference PGA message set,
where it's very minimal information and you
just say, "Hey, I know this product falls
under an HGS code that you might be
looking for, you know at GOC or COC
or basically the testing information,
but I have an exemption, here's why."
So, it's a small, minimal amount of data to try
to lessen the burden, but from our perspective
to know that you understood that
you needed to file something
and that you didn't just not
file testing information.
We need something to tell us that,
"Hey, yeah I know about this.
This is why I'm exempt."
>> Thank you.
>> This is Ken from Walmart.
I guess a couple thoughts I have talking about
maybe recommendations for the Beta, you know --
and I think it could be challenging
when you have 100-200 participants,
but I think maybe some more routine
conversations like this throughout the course
of the Beta I think would be helpful.
You know even if it's once every quarter or
a six month tollgate, something like that.
You know certainly we've submitted some written
information, but I can't imagine you get as much
from that as you have from
the conversation here.
I know I certainly wouldn't have.
So, I would encourage just to maybe try to find
opportunities like that just to touch base.
"How are things going?
What do we need to test that we haven't tested?"
That sort of thing.
[clears throat] Excuse me.
And then the other thing I would recommend,
if you haven't thought about it already,
is seeing if there's some way we can test the
trusted trader program as part of that Beta too,
just anticipating that that will be a
component of whatever full implementation is.
I think it would be a good opportunity
to see what that might look like.
And certainly to the extent that we're a
Beta pilot participant we would be happy
to be a tested trader in that.
Test it out for you.
>> [laughter] Thank you.
>> All right.
You know I would sort of open it up for anyone
that has any last comments, suggestions,
recommendations, anything they would sort
of like to say as part of this meeting and,
you know then we'll kind of
go from there and close up.
All right.
Well, okay.
So, again just thank -- I want to thank everyone
for all of their participation in the pilot,
for making yourself available
and participating today.
This is -- I agree with Ken -- you know you
can get written feedback and that's helpful,
but to actually be able to have a conversation
and ask questions and have a dialogue,
there's -- it's -- you know
there's no substitute for that.
So, I agree with you.
As we move forward I hope that everyone
is recognized, that we've been willing
and available to talk, and you know having
these public meetings is also very helpful.
And if we're able to move to
the Beta I certainly expect
that we will continue to do that.
So, I again just thank you for all of your
work over the last several months to prepare
and to program and to participate and file data.
This has been very helpful for us.
Like I mentioned earlier, we're going
to prepare a report for the commission,
you know with the evaluation of the Alpha and
some options and a recommendation for moving
to a Beta and then we'll await commission
guidance as far as the path forward.
So -- but thank you again and I think
with that we will conclude our meeting.
And thank you to everyone on the phone and
everyone that viewed the webcast today.
Have a good day.