M***M
发帖数: 319 | 1 我也有同样的问题，不明白inventory data and demand data 之间的区别。置顶FAQ只
解释demand data.没有说明两者的区别。
能请你再解释一下两者热区别吗？
谢谢！ |
m**x
发帖数: 8454 | 2 我看了一下FAQ，结论是demand data 是预批好了的485，数字包括副申请人在内。
inventory是pending的，包括预批的没批的，不过不知道包括不包括副申请人。 |
m**x
发帖数: 8454 | 3 不过fuwu你有必要锁帖么。没人回帖帖自己会沉。版务有所为也要有所不为，管那么多
不嫌累么？ |
d*****8
发帖数: 402 | 4 人家积极管理班务，总比消极怠工好。咱就别打击人家积极性了。我们来讨论
inventory data 哈
【在 m**x 的大作中提到】
: 不过fuwu你有必要锁帖么。没人回帖帖自己会沉。版务有所为也要有所不为，管那么多
: 不嫌累么？
|
y******0
发帖数: 8807 | 5 既然有这个区别，那是demand里的数字小于不到一个月的量就开闸，还是inventory里
的量? |
m**x
发帖数: 8454 | 6 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里
: 的量?
|
c*******6
发帖数: 686 | 7 好像少于1个季度就该开闸了
没有非要等到一个月吧
【在 y******0 的大作中提到】
: 既然有这个区别，那是demand里的数字小于不到一个月的量就开闸，还是inventory里
: 的量?
|
m**x
发帖数: 8454 | 8 不知道你说一个季度有什么根据。
eb3开闸的时候好像才剩一两百个demand了
【在 c*******6 的大作中提到】
: 好像少于1个季度就该开闸了
: 没有非要等到一个月吧
|
f**u
发帖数: 2769 | 9 有些ID认为可以通过忽悠奥本达到提前放水的目的。
这样想也挺好的，可以给人以希望。
【在 m**x 的大作中提到】
: 不知道你说一个季度有什么根据。
: eb3开闸的时候好像才剩一两百个demand了
|
c*******6
发帖数: 686 | 10 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了
|
|
|
c*******6
发帖数: 686 | 11 提不提前放水还是OB说了算 积极一点总是好的
大胆猜测一下：
OB 认为EB2I/EB2C的水放得太大了 所以EB3ROW 放水很小心 结果步子迈小了 ：）
【在 f**u 的大作中提到】
: 有些ID认为可以通过忽悠奥本达到提前放水的目的。
: 这样想也挺好的，可以给人以希望。
|
f**u
发帖数: 2769 | 12
这个我以前说过一个解释，可以用一个理论把两次放水统一起来。就是奥本根据前一年
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吧 按照月批准量前进就好了
|
c*******6
发帖数: 686 | 13 分析很到位
这样的话EB3ROW 比EB2C/I 要控制，不存在SO的问题，只有一个变量 申请人的数量。
EB2C/I 放水要注意两个变量，可用的Visa Number 和 申请人数量。
难道 OB 没注意到 USCIS 处理流水线平均要4个月，
他不会等流水线基本清空了以后再注满流水线吧，太浪费资源了。 ：）
【在 f**u 的大作中提到】
:
: 这个我以前说过一个解释，可以用一个理论把两次放水统一起来。就是奥本根据前一年
: SO量来套当年的，进而高估了那一年可以收进I/C的数量。从上次demand data后面三段
: 话来看，他这次放水是想尽量避免“unnecessary fluctuation”。他的方法没法保证
: 不倒退，于是只能慢慢进。
: 第一次奥本弄错了，NIU 一提出他就改了。
|
f**u
发帖数: 2769 | 14 按照现在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个月，
: 他不会等流水线基本清空了以后再注满流水线吧，太浪费资源了。 ：）
|
M***M
发帖数: 319 | 15 多谢你的回复。现在算是明白了。那么，需求总数=Inventory data + Demand data+CP
.如果中国的EB2拿不到一点SO.2800 visa number只够用半年呀。
【在 m**x 的大作中提到】
: 我看了一下FAQ，结论是demand data 是预批好了的485，数字包括副申请人在内。
: inventory是pending的，包括预批的没批的，不过不知道包括不包括副申请人。
|
m**x
发帖数: 8454 | 16 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只够用半年呀。
|
l*******n
发帖数: 8388 | 17 FUWU说“奥本根据前一年SO量来套当年的”。现在奥本已经知道eb2c吃不到SO，那么下
次放水应该很节制。 |
c*******6
发帖数: 686 | 18 不是OB知道EB2C 吃不到SO 是他不让吃吧
怎么放水他说了算啊
按照目前OB 行事风格，
EB2I 排期如果赶上了EB2C
EB2c 才有SO吃
如果在EB2C 到达2010/05前
EB2C还赶不上 EB2C 还得是小水细流
【在 l*******n 的大作中提到】
: FUWU说“奥本根据前一年SO量来套当年的”。现在奥本已经知道eb2c吃不到SO，那么下
: 次放水应该很节制。
|
