Redian新闻
>
TO FUWU:Inventory data and Demand data 区别
avatar
TO FUWU:Inventory data and Demand data 区别# EB23 - 劳工卡
f*c
1
我10月中旬用OPT开始工作,明年还可以延期17个月(STEM)。
我问HR什么时候可以sponsor H1b,回答说他们名额用完了,可能要等17个月以后。现
在他们不能保证何时才能给我办。这是个4万员工的公司呀,怎么会这样。
这正常么?是不是taking advantage??
今天就要我accept offer, 我如果觉得这是个大问题就拒了他们的offer了!
在线等,多谢!
avatar
M*M
2
我也有同样的问题,不明白inventory data and demand data 之间的区别。置顶FAQ只
解释demand data.没有说明两者的区别。
能请你再解释一下两者热区别吗?
谢谢!
avatar
p*j
3
不正常
avatar
m*x
4
我看了一下FAQ,结论是demand data 是预批好了的485,数字包括副申请人在内。
inventory是pending的,包括预批的没批的,不过不知道包括不包括副申请人。
avatar
f*c
5
顶一下,谢谢。
avatar
m*x
6
不过fuwu你有必要锁帖么。没人回帖帖自己会沉。版务有所为也要有所不为,管那么多
不嫌累么?
avatar
l*o
7
我当时offer letter里面也没有写h1b 但是我后来问公司 他们说都不会写的 只是口
头上说会办
avatar
d*8
8
人家积极管理班务,总比消极怠工好。咱就别打击人家积极性了。我们来讨论
inventory data 哈

【在 m**x 的大作中提到】
: 不过fuwu你有必要锁帖么。没人回帖帖自己会沉。版务有所为也要有所不为,管那么多
: 不嫌累么?

avatar
w*e
9
Ask them the policy.
avatar
y*0
10
既然有这个区别,那是demand里的数字小于不到一个月的量就开闸,还是inventory里
的量?
avatar
m*x
11
obviously demand data
inventory -> demand -> bulletin
bulletin is based on demand, not inventory.
some pending 485 cases in inventory can be rejected

【在 y******0 的大作中提到】
: 既然有这个区别,那是demand里的数字小于不到一个月的量就开闸,还是inventory里
: 的量?

avatar
c*6
12
好像少于1个季度就该开闸了
没有非要等到一个月吧

【在 y******0 的大作中提到】
: 既然有这个区别,那是demand里的数字小于不到一个月的量就开闸,还是inventory里
: 的量?

avatar
m*x
13
不知道你说一个季度有什么根据。
eb3开闸的时候好像才剩一两百个demand了

【在 c*******6 的大作中提到】
: 好像少于1个季度就该开闸了
: 没有非要等到一个月吧

avatar
f*u
14
有些ID认为可以通过忽悠奥本达到提前放水的目的。
这样想也挺好的,可以给人以希望。

【在 m**x 的大作中提到】
: 不知道你说一个季度有什么根据。
: eb3开闸的时候好像才剩一两百个demand了

avatar
c*6
15
1.EB2C/EB2I 放水时候的demand
EB2C剩3K EB2I剩5K 的时候就开始放水了
这岂不是一年的量?考虑到EB2可以拿到SO
差不多是一个季度的批准量吧 那一年 老中吃了不少SO
2.EB3ROW 开闸放水的时候 出过两个版本的demand
4月8号的一个是7825 基本是一个季度吧
4月9号的一个是2000 不知道为什么?
3.EB3C 开闸放水的时候 是5月份
3、4月份 EB3ROW 都还没有开闸
不能因为EB3C 太少就让他超过EB3ROW吧 按照月批准量前进就好了
5月份 EB3C和EB3ROW 一起开的闸

【在 m**x 的大作中提到】
: 不知道你说一个季度有什么根据。
: eb3开闸的时候好像才剩一两百个demand了

avatar
c*6
16
提不提前放水还是OB说了算 积极一点总是好的
大胆猜测一下:
OB 认为EB2I/EB2C的水放得太大了 所以EB3ROW 放水很小心 结果步子迈小了 :)

【在 f**u 的大作中提到】
: 有些ID认为可以通过忽悠奥本达到提前放水的目的。
: 这样想也挺好的,可以给人以希望。

avatar
f*u
17

这个我以前说过一个解释,可以用一个理论把两次放水统一起来。就是奥本根据前一年
SO量来套当年的,进而高估了那一年可以收进I/C的数量。从上次demand data后面三段
话来看,他这次放水是想尽量避免“unnecessary fluctuation”。他的方法没法保证
不倒退,于是只能慢慢进。
第一次奥本弄错了,NIU 一提出他就改了。

【在 c*******6 的大作中提到】
: 1.EB2C/EB2I 放水时候的demand
: EB2C剩3K EB2I剩5K 的时候就开始放水了
: 这岂不是一年的量?考虑到EB2可以拿到SO
: 差不多是一个季度的批准量吧 那一年 老中吃了不少SO
: 2.EB3ROW 开闸放水的时候 出过两个版本的demand
: 4月8号的一个是7825 基本是一个季度吧
: 4月9号的一个是2000 不知道为什么?
: 3.EB3C 开闸放水的时候 是5月份
: 3、4月份 EB3ROW 都还没有开闸
: 不能因为EB3C 太少就让他超过EB3ROW吧 按照月批准量前进就好了

avatar
c*6
18
分析很到位
这样的话EB3ROW 比EB2C/I 要控制,不存在SO的问题,只有一个变量 申请人的数量。
EB2C/I 放水要注意两个变量,可用的Visa Number 和 申请人数量。
难道 OB 没注意到 USCIS 处理流水线平均要4个月,
他不会等流水线基本清空了以后再注满流水线吧,太浪费资源了。 :)

【在 f**u 的大作中提到】
:
: 这个我以前说过一个解释,可以用一个理论把两次放水统一起来。就是奥本根据前一年
: SO量来套当年的,进而高估了那一年可以收进I/C的数量。从上次demand data后面三段
: 话来看,他这次放水是想尽量避免“unnecessary fluctuation”。他的方法没法保证
: 不倒退,于是只能慢慢进。
: 第一次奥本弄错了,NIU 一提出他就改了。

avatar
f*u
19
按照现在DOS和USCIS之间的通讯协议,DOS只能在USCIS审理完一个case之后,request
visa number的时候才首次知道这个case的存在。他在两条流水线(CP,AOS)的末端试
图控制调整前端的进货量,但对其中一条流水线(AOS)里面各个环节的具体情况一无
所知,怎么可能准确。

【在 c*******6 的大作中提到】
: 分析很到位
: 这样的话EB3ROW 比EB2C/I 要控制,不存在SO的问题,只有一个变量 申请人的数量。
: EB2C/I 放水要注意两个变量,可用的Visa Number 和 申请人数量。
: 难道 OB 没注意到 USCIS 处理流水线平均要4个月,
: 他不会等流水线基本清空了以后再注满流水线吧,太浪费资源了。 :)

avatar
M*M
20
多谢你的回复。现在算是明白了。那么,需求总数=Inventory data + Demand data+CP
.如果中国的EB2拿不到一点SO.2800 visa number只够用半年呀。

【在 m**x 的大作中提到】
: 我看了一下FAQ,结论是demand data 是预批好了的485,数字包括副申请人在内。
: inventory是pending的,包括预批的没批的,不过不知道包括不包括副申请人。

avatar
m*x
21
I didn't say 需求总数=Inventory data + Demand data+CP, I don't think you
understand me yet.
and I totally lost you on "2800 visa number只够用半年"

CP

【在 M***M 的大作中提到】
: 多谢你的回复。现在算是明白了。那么,需求总数=Inventory data + Demand data+CP
: .如果中国的EB2拿不到一点SO.2800 visa number只够用半年呀。

avatar
l*n
22
FUWU说“奥本根据前一年SO量来套当年的”。现在奥本已经知道eb2c吃不到SO,那么下
次放水应该很节制。
avatar
c*6
23
不是OB知道EB2C 吃不到SO 是他不让吃吧
怎么放水他说了算啊
按照目前OB 行事风格,
EB2I 排期如果赶上了EB2C
EB2c 才有SO吃
如果在EB2C 到达2010/05前
EB2C还赶不上 EB2C 还得是小水细流

【在 l*******n 的大作中提到】
: FUWU说“奥本根据前一年SO量来套当年的”。现在奥本已经知道eb2c吃不到SO,那么下
: 次放水应该很节制。

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。