HANDOUTS FROM 2/10 MEETING (Topic #1):Sanctioning/Post-Season Choices And Your Team BillDue to interest expressed at yesterday's membership meeting, please note that ECTB World Series have been added as program options at 9u-10u-11u-12u. This offering is subject to how many teams sign up to compete for these berths. If any of the latter are cancele... read more

More Drills & Trick Plays - Youth Baseball (Videos) Click here to watch.

HANDOUTS FROM 2/3 MEETING:NEW MEMBERS ORIENTATION CLICK HERE to see why ENYTB is a great league choice for every travel team, regardless of age, ability or post-season aspirations; CLICK HERE for an overview of ENYTB's organizational structure; CLICK HERE to view a timeline of ENYTB's historical development; CLICK HERE to view a schematic of ENYTB'... read more

More Drills & Trick Plays - Youth Baseball (Videos) Click here to watch.

Handouts From 1/27 Meeting:ANNUAL KICK-OFFTo view the handouts from the 2013 Kick-Off Meeting: CLICK HERE for an overview of post-season opportunities available to ENYTB members; and, CLICK HERE for an overview of ENYTB's new system for balancing roster protection and player movement.

ENYTB Adds ECTB Sanctioning and 19U Age Division in 2013.ENYTB will be purchasing berths to all of the ECTB World Series events in 2013. These tournaments are hosted in the eastern PA area. These tournaments are half the cost of CABA tournaments and the competition is more realistic that encountered at CABA (more similar to the level of competition... read more

Youth Baseball Traing Drills - VideosClick here to view. Click here to view/order backyard portable training mound ($149).

Allowed Variances ("Loopholes") In Age Eligibility By Sanctioning Bodies As Well As ENYTB's Own Rules On Allowing Over-Aged PlayersGENERALA player's baseball age is typically defined as his age on April 30 of the current year and a team's age is typically determined by the age of its oldest player. Using this standard, a team would need all players... read more

Important 2013 Rule Changesre: Roster Protection/Player Movement/Releases etc. Background/Guiding League PhilosophyUnlike other local travel leagues, ENYTB does not rely on territorial boundaries to limit a player's opportunity to play baseball. All first-time ENYTB players have the freedom of choice as to what club/team to play for. That has not ... read more

CAPOLOGY 101 - More DetailedACHIEVING LIMITED BUT VERIFIABLE ROSTER PROTECTION FOR ALL ENYTB TEAMS VIA A SYSTEM OF INTRA-LEAGUE PLAYER CAPSWARNING: The complete system is presented below at the level of detail required for developing computer code. Much of that detail will not be useful to the general reader. Use similar to a reference manual (not to be read in its entirety in one sitting).12 STEP METHODOLOGY:INDEX--------------------------------------------------------------❶ PLAYER CLASSIFICATION❷ GENERAL CAP STRUCTURE – THE MOVING PARTS❸ PLAYER TRANSACTIONS – THE NUTS & BOLTS❹ DETERMINING TEAM CAPS – THE INS AND OUTS❺ USED CREDITS – ARE DETERMINED FROM THE PRIOR ROSTER STATUS OF EACH PLAYER ON A TEAM’S CURRENT ROSTER❻ CAP EXEMPTIONS – RFA THAT COUNT AS UFA❼ CAP ADMINISTRATION/ENFORCEMENT – AUTOMATED❽ ROSTER CUT FUNCTION❾ WASHED (OR LAUNDERED) PLAYERS – ILLEGAL PLAYER TRANSACTION❿ TRANSFERRING PLAYERS TO NON-ROSTER LISTS⓫ INTRA-CLUB PLAYER TRANSFER FUNCTION⓬ OVERVIEW FROM PARENT/PLAYER PERSPECTIVE, INCLUDING REAL TIME TOOLS THAT DETERMINE TEAM & PLAYER SPECIFIC CAP ELIGIBILITY--------------------------------------------------------------❶ PLAYER CLASSIFICATIONRoster protection depends on limiting the number of players any ENYTB team can take from all other ENYTB teams combined as well as from any single ENYTB team. To this end, the universe of all players shall be divided into two general groups: unrestricted free agents (UFA) and restricted free agents (RFA).(A) Unrestricted Free Agents (UFA) – The current status of any player not on a current team=s (active or inactive) ENYTB roster is UFA. For the most part, UFA includes all players who did not participate in ENYTB in the prior spring/summer season. UFA are uncapped i.e., they are an unlimited source of players for all ENYTB teams, new and existing.(B) Restricted Free Agents (RFA) – The current status of any player on a current team=s (active or inactive) ENYTB roster is RFA. Except for players that have been cut between then and now, this includes all players that played in the league in the prior spring/summer season as well as any that have been added to a current team’s roster since.RFA are capped i.e., they are a limited source of players for all ENYTB teams, new and existing i.e., each team is entitled to a limited number of RFA in the current period.NOTE: Teams also can place players that did not report (not coming back but didn’t sign up with another ENYTB team) on their “DNR” list, defined below, for up to two years. A player on a DNR list remains an RFA for as long as he remains on the DNR list. If the player doesn’t get picked up by another team before the conclusion of this period, he shall become an UFA.❷ GENERAL CAP STRUCTURE – THE MOVING PARTSTo achieve intra-league roster protection, the league shall impose limits or caps on the number of players any ENYTB team can add in the current period from the pool of all players currently on the rosters of all other ENYTB teams (active or inactive) as well as from the same pool for any individual team. The players that make up this pool are defined as restricted free agents (RFA). Altogether, there are three RFA caps. They are:(A) CAP1 - Limits the overall number of RFA any ENYTB team can add in the current period from the pool of all players currently on the rosters of all other ENYTB teams (active or inactive); (B) CAP2 – Limits the number of RFA any ENYTB team can take from the roster of any specific ENYTB team in the current period (annual head-to-head cap or H2H1). CAP2 is defined for every ENYTB team B vis a vis every other ENYTB team A, where team B is defined as the team the RFA has “switched to” and team A is defined as the team the RFA has left or “switched from”; and,(C) CAP3 – Limits the number of RFA any ENYTB team can take from the roster of any specific ENYTB team in the prior five year period, including the current period (five year head-to-head cap or H2H5). Like CAP2, CAP3 is defined for every ENYTB team B vis a vis every other ENYTB team A.❸ PLAYER TRANSACTIONS – THE NUTS & BOLTSPrior to describing how individual team RFA caps are arrived at and the various exemptions thereto, it is useful to introduce the concept of a player transaction and to have a general understanding of which types of player transactions are subject to the various caps i.e., CAP1, CAP2 and CAP3 and which ones are not subject to any caps.GENERALIZED PLAYER TRANSACTION:Player A – is defined as any player that is the subject of a player transaction.Team A – is defined as the current team of player A prior to the player transaction, if any.Team B – is defined as the current team of player A after the player transaction has been completed, if any.Examples: Generic Transactions For Primary Players: (A) ADD Transaction: Player A, RFA Primary on Team A, “Switches” To RFA Primary on Team B (player A is removed from roster of team A and added to roster of team B)(B) ADD Transaction: Player A, UFA, Is Added By Team B, RFA Primary (player A is added to roster of team B as RFA Primary)(C) CUT1 Transaction: Player A does NOT ask to be cut: Player A, RFA Primary on Team B, Is Cut By Team B. Player A is removed from roster of team B and is reclassified UFA.(D) CUT2 Transaction: Player/family asked team to cut player A: Player A, RFA Primary on Team B, Is Cut By Team B At Player’s Request - player A is removed from roster of team B and is reclassified RFA*, because the cut was at the player’s request, not the team’s)NOTE: RFA* indicates player is subject to CAP1 for next team B but not CAP2/CAP3. Also, prior team B does not get credited with an RFA loss.Player Transactions: Primary vs SecondaryENYTB allows players to play on multiple ENYTB teams during the same season, provided each team is registered in a different age division. One of the player=s teams must be designated as primary i.e., the team that the player must give first priority to in the event of any conflicts. All other teams that the player might play for are designated as secondary. NOTE: A player=s primary team is usually the ENYTB team that first added him to its roster (default) but that is not necessarily so. A player could change primary teams w/o changing secondary teams. Also, a player’s primary team could fold or leave the league, making the player’s secondary team his new primary team by default. Cap restrictions only apply to player transactions involving RFA Primary i.e., all RFA can change secondary teams w/o restriction.Example: Primary Transactions & Whether Subject To Team B’s Cap Restrictions):• Primary ADD: UFA  RFA: Primary Team B = no cap effectPlayer A is added to roster of team B as RFA: Primary.• Primary SWITCH: RFA: Primary: Team A C> RFA: Primary: Team B = full cap effect Player A is removed from roster of team A and added to roster of team B as RFA:Primary.• TO SWITCH FROM SECONDARY TO PRIMARY (2 separate transactions)--> CUT: RFA: Secondary: Team S--> Primary SWITCH: RFA: Primary: Team A C> RFA: Primary: team B (where team B = prior secondary team S) = full cap effectPlayer A is removed from roster of both secondary team S and primary team A and added to roster of team B (which, in this case, = team S) as RFA: Primary.Example: Secondary Transactions:(If Player Is Being Picked Up as a Secondary Player = no cap effects)• SECONDARY ADD: RFA: Secondary: Team S(where age of team S not = age of RFA: Primary team B or age of any other team that player may be secondary with))-->Player A = RFA:Primary Team B + RFA:Secondary Team S (no cap effect)Player A is simply added to roster of team S as RFA: Secondary.• SECONDARY SWITCH: RFA: Secondary: Team S1  RFA: Secondary: Team S2 (where age of team S1 = age of team S2 and age of team S2 is not = age of team B where player A = RFA: Primary) --> Player A = RFA: Secondary Team S2 + RFA: Primary Team B (no cap effect) Player A is removed from secondary team S1 and added to team S2 as RFA:Secondary. ❹ DETERMINING TEAM CAPS – THE INS AND OUTSThis section provides the information you need to calculate your own team caps, though the website already does that for you.* Club/Team Eligibility For RFA CreditsTo be eligible for RFA credits, the team, new or existing, must be owned by a “continuing” member. The latter is defined as clubs that, as a matter of practice, continue their teams in ENYTB from year to year.Non-continuing members do not, as a matter of practice, continue their teams in ENYTB beyond a certain age. Instead, these clubs routinely switch their teams to another league as they age up e.g., American Legion, Babe Ruth affiliated travel leagues etc. and, as a result, discontinue their participation in ENYTB. This restriction also is not applicable to clubs that register their older aged teams in ENYTB as well as another league.Teams owned by a “non-continuing” member are not eligible for any RFA credits i.e., their rosters must be comprised of UFA only.NOTE: This restriction is not applicable to clubs with teams that become defunct due to natural causes only e.g., they can’t get not enough players, they don’t have a manager, etc. * Overall RFA Credits (CAP1) = Base + Compensatory + BonusEach year, any team owned by a “continuing” ENYTB member club shall be allotted a certain number of overall RFA Credits (CAP1). This number determines the maximum number of RFA a team can add to its roster in the current period. CAP1 can vary from year to year and from team to team depending on various factors as shown below. The starting overall RFA cap number in any current period is comprised of three components, each of which can vary from year to year and team to team for various reasons, as shown next.CAP1X - Existing Teams (teams registered in league in prior year)Base Credit = 1 MAX for all teams unless three year look-back restriction (described below) applies, then = 0;$ Compensatory Credit = 1 MAX for all teams that lose three or more RFA in current period (RFA losses described below*); and,$ Bonus Credits per League Review (no set MAX) - a bonus allotment of overall RFA Credits may be awarded based on extreme or extenuating circumstances affecting a team’s viability, subject to league determination/approval.CAP1N - New Teams (teams not registered in league in prioryear)$ Base Credits = MAX 5 (Majority Rule) in Year 1$ Base Credit = MAX 1 after Year 1 (same as existing)$ Compensatory Credit* = MAX 0 in Year 1$ Compensatory Credit* = MAX 1 after Year 1 (same as existing)$ Bonus Credits = By League Review in Year 1 (same as existing)$ Bonus Credits = By League Review after Year 1 (same as existing)*DETERMINATION OF COMPENSATORY CREDIT – A team’s compensatory credit in the current period is determined by its RFA losses in the same period. RFA losses in the current period for any team A can be obtained by summing across all current period H2H1 RFA adds by all other team B’s vis a vis that Team A. EXAMPLE: RFA losses for Team A in current period is as follows:H2H1 RFA Losses of Team A vis a vis Team B1 = 1H2H1 RFA Losses of Team A vis a vis Team B2 = 1H2H1 RFA Losses of Team A vis a vis Team B3 = 2H2H1 RFA Losses of Team A vis a vis All Other Team B = 0------------------------------------------------------------------H2H1 RFA Losses of Team A vis a vis All Other Teams = 4Since 4 > or = 3, Team A compensatory RFA credit = 1.G Look-Back Rule - Applicable Equally to New and ExistingTo discourage teams from building a powerhouse team exclusively at their fellow members’ expense, the base RFA credit is variable, depending on how many primary RFA players w/o exemption a team has added in the most recent three year period. If a team has added five or more primary RFA (w/o exemption) in the last 3 years, not counting the current year, that team shall forfeit its base RFA allowance in the current year.Base Credit Per T (except for year 1 new) = 0 if total RFA added in T-1 + T-2 + T-3 > 4;Else, Base Credit Per T = 1. G Head-to-Head RFA Limits (CAP2/CAP3): There is a MAX number of RFA any team B can take from any team A in any one year (CAP2) as well as over any prior five year period (CAP3). These are referred to as head-to-head caps.For Existing Teams:$ CAP2 - Annual MAX = 1; and,$ CAP3 - 5 Year MAX = 2For New Teams:$ CAP2 - Year 1 MAX = 2; and,$ CAP3 - 5 Year MAX = 2NOTE: CAP2 allows new teams to accelerate their full 5 year H2H RFA allowance into their year one H2H RFA allowance.❺ USED CREDITS – ARE DETERMINED FROM THE PRIOR ROSTER STATUS OF EACH PLAYER ON A TEAM’S CURRENT ROSTERThis information in this section, along with section 3, player transactions, and section 4, determining team caps, is sufficient to determine the cap effects of any player addition as well as any team’s remaining cap space, though the website already does that for every team i.e., it automatically updates the team caps, used credits and remaining cap space, in real-time. This information is available to all teams and parents/families at all times. A player’s current status is defined in real time i.e., what is he right now. A player’s prior status defined by his status immediately prior to the most recent player transaction that he was a part of i.e., prior status is frozen in time based on the player’s most recent player transaction. For example, by definition, the current status of any primary player is RFA: Primary: team B, where team B is the last team to acquire him. Similarly, the current status of any player not on a primary roster is UFA. In either case, however, the same player’s prior status could be UFA or primary RFA, depending on whether he was a UFA or RFA when he was acquired by his current team. When a player is added to any primary team B, his prior status is recorded on the roster of his new team. This information is used to calculate “used” CAP1, CAP2 and CAP3 (and CAP4 and CAP5 for the playing up exemption, described below). If he was classified = UFA when added, his prior status = UFA and he does not use any cap space. If, however, he was RFA: Primary on another team’s roster when acquired, his prior status = RFA: Primary: team A = team ABC. (In the case of a player with a prior status = RFA: Primary, the name of his prior primary team A shall be recorded as well.) The latter is used to compute RFA losses for team A as well as used CAP2 and CAP3 between team A and new team B. IMPORTANT:A player’s prior status (UFA/RFA) is fixed once a player is added to his current team’s roster and remains so for as long as the player remains on the roster of that team B.Thus, if a player’s prior status = RFA: Primary and his prior primary team A is deleted from the league at a later time, his prior status shall remain = RFA: Primary but his prior primary team A will change to none. W/o a primary team A, the history for both CAP2/CAP3 for his team B vis a vis his prior team A is no longer defined. Thus, neither the player’s prior status nor current status is affected by the fact team A was deleted after the player transaction was completed, other than his prior primary team A = none and the historical CAP2/CAP3 numbers between his new team B and his prior team A become irrelevant. The algebra of cap space and its dependence on the timing between when a player is added by team B and the current status of a player’s prior team A:Example 1: Player A: primary team A  primary team B(1) Initial Status (current period) = RFA: Primary w team XYZ(2) DEC 1 2012 - Player Transaction = SWITCH: Team JKL (team B) adds player as primary;Player Transaction: consumes one RFA credit under all three CAPS for Team B; and,Team XYZ (team A) gets credit for loss of one RFA.Updated Current Status = RFA: Primary w Team JKL (team B)Updated Prior Status = RFA: Primary w Team XYZ (team A) (note: this info is recorded on roster of team B and remains unchanged until a new player transaction removes player from roster of team B)Now, let’s suppose player’s prior primary team XYZ (team A) fails to re-activate for the current season and gets deleted on January 16. Example 2: Player A: primary team A  primary team B Primary team A  deleted (1) Initial Status (current period) = RFA: Primary: team XYZ(2) DEC 1 2012 - Player Transaction = SWITCH: Team JKL (team B) adds player as primary;Player Transaction: consumes one RFA credit under all three CAPS for Team B; and,Team XYZ (now team A) gets credit for loss of one RFA.Updated Current Status = RFA: Primary: Team JKL (team B)Updated Prior Status = RFA: Primary: Team XYZ (team A) (note: this info is recorded on roster of team B and remains unchanged until a new player transaction removes player from roster of team B)(3) JAN 16 2012 - Team XYZ (prior team A) is deleted.NOTE: (3) is not a player transaction. Update: Current Status = RFA: Primary: team JKL (no change)Update: Prior Status = RFA: Primary: team XYZ (no change)Update: Unused CAP1 For Team B = (no change)Update: Prior Primary team A = None (CHANGED)Update: team B/team A CAP2/CAP3 = UNDEFINED. (CHANGED)Update: team A RFA losses = UNDEFINED. (CHANGED)Same example except suppose:Team B waited until February, after player’s team A is deleted, to add the same player:EXAMPLE 3: Primary team A  deleted.Player A (primary on team A previous to deletion)  added by team B as primary (1) Initial Status (current period) = RFA: Primary: team XYZ;(2) JAN 16 2012 Player Transaction = CUT: Player CUT by team XYZ; Current Status = UFAPrior Status = RFA: Primary: Team XYZ (team A)(3) FEB 1 Player Transaction = ADD: team JKL (team B) adds player as primary;Update Current Status = RFA: Primary: Team JKL (team B) (no change)Update Prior Status = UFA (no change)Update: Prior primary team A = none (CHANGED)Update: team A credit for RFA loss = UNDEFINED. (CHANGED)Update: CAP1 – All UFA = Uncapped: Used CAP1 = No change for Team B (CHANGE); and,Update: CAP2 & CAP3 = UNDEFINED (no team A) (no change – note: CAP2/CAP3 = undefined for all UFA and all team A = none)The above examples illustrate the importance of timing in determining a team’s prior status, which, in turn, determines whether team B must count player A against its CAPS.NOTE: We could have used an approach that updated a player=s status in real time i.e., a player added as prior status = RFA would dynamically update to prior status = UFA if/when his prior primary team A was deleted. Under this approach, player A would no longer count against the CAPS of team B. The rationale for not choosing this approach is that more often than not, a team folds because it has lost key players or too many players to other teams. This approach would have “rewarded” the players who jump ship early (and their new teams) with a UFA classification after the fact. For this reason, we believe it is far better to define a player’s prior status relative to the situation that exists at the time the player makes the SWITCH. So, should a team B add an RFA to his roster as soon as possible or should it wait to see whether team A continues in the league? Clearly, if a team B has a solid commitment from a player, and is unsure if the player=s former team A will continue in the league in the current period, it may be strategically wise to wait until at least late in the day on Jan 16 to add the player. By then, team A will be deleted by league admin if it has not re-activated itself. Thus, team B might get lucky and avoid using an RFA credit on him. On the other hand, teams must keep in mind that MAR 1 is the deadline for adding RFA (except for new teams added after Feb 15 which are given two weeks from date team is added to website). So, if a team waits too long and the player’s prior primary team does not fold, it will lose the ability to add the player to its roster for that entire season.EXCEPTIONS to MAR 1 CUTOFF FOR RFA: New teams added after Feb 15 shall be given two weeks from the time they activate their team to add all RFA. ❻ CAP EXEMPTIONS – RFA THAT COUNT AS UFAAll RFA are treated the same except for:(1) RFA*, described below (CUT by request of player/family); and,(2) RFA that qualify for any of three special exemptions, discussed next.The prior status of any RFA qualifying under any exemption shall be designated as “exempted”. All exempted RFA shall be treated exactly the same as an ordinary UFA as far as applicability of team RFA caps are concerned i.e., they are not subject to CAP1, CAP2 or CAP3. EXEMPTION #1: FRANCHISE PLAYERS This exemption is available to franchise, co-franchise and sub-franchise members only.It is applicable to players residing in the member>s franchise area but currently playing for a club with either no territory assignment or with territory that does not include the player’s resident public school district.In this situation, such players shall be allowed to switch from team A to any team B owned by their home area club w/o counting against ANY of that team=s RFA caps i.e., for that team B, the player shall be treated the same as an UFA. NOTE: Since an RFA with an exemption is treated the same as an UFA, he does not count against any of the three RFA CAPS for team B. Thus, he also does not count as an RFA loss for team A. This is true of all players with exemptions.NOTE: A player=s home area club is determined by the public school district that he resides in. If a player has more than one home area club e.g., co-franchise, the exemption will apply to either unless the player is moving from one home are club to another, in which case this exemption shall not apply.EXEMPTION #2: PLAYING-UPAll amateur youth sports leagues are obligated, by legal precedent, to make players eligible to play-up.To qualify for this exemption a player must be switching to an older aged primary team, where the player’s current club does not have a current team already established in the same older aged division i.e., active in the same age or inactive from the prior season at one year younger. This exemption is available to all RFA and all teams, new and existing, but each team B shall be limited to a maximum of two such exemptions in the current period (CAP4) and a maximum of two such exemptions lifetime vis a vis any team A (CAP5).NOTE: This exemption is limited (via CAP4 and CAP5) to prevent new teams from forming with the intent of defeating our H2H player movement restrictions by registering a group of RFA in an age division one year higher than what they would normally participate for the sole purpose of qualifying the entire group of players under this exemption.This exemption allows an RFA to switch to any eligible older-aged team w/o counting against that team=s RFA caps, other than CAP4 and CAP5, provided the player=s current club does not have a current team (active or inactive) in the same age division. If the player=s current club has a current team in the same age division, this exemption shall not be applicable unless that club refuses to move the player up to the higher aged team. In this situation, the player may apply to the league for an exemption under this provision (the ADD PLAYER logic will not recognize this exemption under this circumstance). NOTE: Any player not qualifying for a “free” switch to an older-aged team can still do so as an ordinary RFA, subject to the RFA caps of team B.NOTE: A Acurrent team@ is defined as any team owned by an ENYTB member, active or inactive, that was added to the ENYTB website prior to team B adding the player to its online ENYTB roster. Thus, if a player qualifies under this exemption and is added to team B, and if the player’s prior club subsequently adds a new team in the same age division, that action will not negate any prior player transactions under this exemption.EXEMPTION #3 SIBLING CREDIT – 2 for 1This exemption shall be applicable to families with two or more players of similar age, all of whom are classified RFA: Primary on any team A. The sibling credit allows all qualifying players from the same family to switch to the same team B (RFA: primary) for one CAP credit. To accomplish this, the team B shall be granted a bonus credit for its CAP1 and CAP2/CAP3 vis a vis team A. This approach has the added advantage of giving the team A credit for two (or more) RFA losses via the CAP2 summation method.Qualification Requirement: To qualify for this exemption, the players must share the same address and the team B must notify the league administrator of the situation. ❼ CAP ADMINISTRATION/ENFORCEMENT – AUTOMATEDOnce there is mutual commitment between any player A and a team B, the latter submits the player transaction to the website via:B> My Team B> Team Roster(s) B> ENYTB B> Add player to my ENYTB Roster The ADD PLAYER function shall determine the player=s ENYTB status and whether he is eligible to be added to the roster of team B. When a player transaction is successfully completed, one or more rosters are automatically updated in accordance with the player transaction. The general logic for evaluating a player transaction request involving an UFA being added to team B as primary or an RFA switching from primary team A to primary team B, is as follows: Determine Player’s Prior Status:(1) If player’s prior status with respect to this player transaction = UFA:RFA cap space = NA;Player is added as primary to the roster of team B; and,Player doesn’t count against any of the unused RFA credits of team B. END (2) If player’s prior status with respect to this player transaction = RFA but the player transaction qualifies player as an RFA exemption for team B:RFA cap space = NA;If exemption = playing-up: test CAP4 and CAP5 unused cap space; Player is added as primary to the roster of team B (w exemption = yes noted in his prior status);Player is removed from the roster of team A and any other team in the same age division as his new primary team B where the player may have been secondary; and, Player doesn’t count against the unused cap space of team B. END(3) If the player’s prior status = RFA w/o an exemption (including DNR): The user is asked whether he wishes to add the RFA on a primary or secondary basis. If primary, Team B must have sufficient cap space for player transaction to be approved.team B’s unused RFA credits > 0System will determine if team B has sufficient unused RFA credits, including unused H2H1 and H2H5 RFA credits vis a vis team A, to acquire this RFA as primary. if unused RFA credits > 0 and H2H1 < 1 (or 2 if new) and H2H5 < 2 Player is added as primary to the roster of team B;Player is removed from the roster of team A and the roster of any other team in the same age division as team B where the player is listed as secondary.  Unused CAP1 credits of team B are reduced by 1.  Unused CAP2 credits of team B/team A are reduced by 1  Unused CAP3 credits of team B/team A are reduced by 1 END NOTE: The information recorded on each team’s current roster is sufficient to determine the number of used credits applicable under each CAP. For example, for team B to add a primary RFA from team A in the current period, a count of already used credits is subtracted from the total allowances determined by the team’s caps to determine the remaining unused cap space, if any. If the transaction is approved, the count of RFA losses for team A also will automatically adjust to this player transaction. Were a team to add a player in a prior period whose prior status = RFA: Primary: team ABC, and then cut the same player in the current period, it would have no effect on unused CAP1 (unless it is the difference between the team qualifying for its base credit) or CAP2, both of which are defined relative to RFA added in the current period only, but it would result in a reduction of CAP3 between team B and team A, provided the player was added in the prior five year period. The bookkeeping for all of these effects is automated within the website. if UNUSED_CAP1 = 0 or UNUSED_CAP2 = 0 or UNUSED_CAP3 = 0, user shall be told via screen message “Team name=” does not have sufficient cap space at this time to add “player name =”. Go to to view your cap positions. ENDNOTE: It is possible for CAP1 credits to increase at a later time in the current period due to additional RFA losses by team B or by addition via League Review. If secondary: Is player already primary in same age division as team B? If yes, team B is told “player name=” is already primary in this age division for “team name=” and is not eligible to appear on the roster of two teams in the same age division. To acquire this player in this age division, “team B name =” would have to add “player name =” as primary. END If no, continue Is player already secondary in same age division as team B? if yes, add player to team B as secondary and remove player from secondary team A in this age division. END if no, add player to team B as secondary. END  PLAYER TRANSACTIONS – SEND NOTIFICATION Via AUTO-EMAIL(1) TEAM SWITCHES(a) Team A NotificationWhenever a player is removed from the roster of any team A (primary or secondary) because the player has been added to any team B, an email shall be sent to that club/team A informing them that the player has left team A (primary/secondary) to join team B (primary/secondary).(b) Player Notification/Request For ConfirmationWhenever a player is added to any roster, as an UFA or RFA, primary or secondary, an email shall be sent to the player informing him of the transaction and asking him to confirm the transaction with an email reply to the league that simply says OK.(2) PLAYER CUTSWhenever a player is CUT from any roster, an email also shall be sent to the player informing him of the transaction and his new status. If CUT1 = UFA – Player is told “You are immediately eligible to sign up with any ENYTB team you choose, w/o restriction.”If CUT2 = RFA* - Player is told “You are eligible to sign up with any ENYTB team you choose, with the following restriction: if you sign with a new team this year or next, you will count against your new team’s unused RFA credits (CAP1 only). Subsequent to that time period, if not already added to the roster of a new team, you will be reclassified as an UFA, and thereafter will be eligible to sign up with any ENYTB team you choose, w/o restriction.”ADMIN TOOLS REQUIRED TO MANAGE PLAYER TRANSACTIONSA chronological list of each approved player transaction shall be maintained online in Admin. The list will show the player’s name (hyperlinked to his name in the player database for easy verification of personal data, etc.), his team A (if any), and his team B. (CUTS count as a player transaction.) Sort player transactions by type to their own list as follows:(a) Player Transactions – ADD UFA (New To ENYTB) – Primary OnlyUndo button.Delete button.(b) Player Transactions – ADD UFA (Existing) – Primary OnlyUndo button.(c) Player Transactions – PRIMARY TEAM SWITCH/RFA - Confirmed v UnconfirmedConfirm/Undo buttons.(d) Player Transactions – CUT1 – Primary OnlyUndo button.(e) Player Transactions – CUT2/RFA* - Primary OnlyUndo button.Confirm – player has replied that transaction is valid. When clicked player is moved from Player Transactions Type = Not Confirmed to Player Transactions Type = Confirmed.Undo - the transaction was successful but must be voided due to a denial of commitment by player or some other reason e.g., mistake. This function shall undo the transaction i.e., restore the player to his exact status prior to the transaction. Where applicable, restore player to his team A roster with the same history as before the transaction as to his UFA/RFA status when acquired and his prior team A, if any. If a team executes a player transaction and the player reports to the league that he did NOT commit to that player transaction with team B, the offending team/club shall be fined $100 for the first offense and higher amounts thereafter, at the discretion of the league. (Pete – do not automate this fine, at least not for the first year.)If a player has no team A, simply remove him from the roster of team B and give him UFA status.Delete – Hyperlink player’s name to his name in player data base. Hyperlink would be used to verify new player is not a duplicate of a player already in the database, most likely a RFA (cheater). For duplicates, this function would delete the player’s duplicate record from the database. ❽ ROSTER CUT FUNCTIONUnder the new player movement system, teams no longer release players. Instead, with the player’s approval, a team enters a player transaction to the website to add the player. If the transaction is legally permissible under ENYTB’s rules re: player transactions, it is approved and the player is automatically removed from his prior team’s roster and added to his new team’s roster. This two-step process is as follows:1. Team B has tangible evidence of a commitment from the player; and,2. Team B has sufficient unused cap space to add player A as an RFA:PrimaryWhen these “team switches” occur, both the team A and the player shall receive auto- email notifications. There also are instances where a player’s current team wants to unilaterally remove the player from its roster, either temporarily or permanently. The cut is one of the several options available to ENYTB clubs and teams for unilaterally removing a player from its ENYTB roster. The others include non-roster lists and are discussed in section 9.CUT – The new system gives clubs the option to cut a player via the CUT function. The reasons causing a club to cut a player may be disciplinary. Or it may be that the player has called it a career, or has moved away, or is not competitive enough to make the team, etc. Regardless of the reason, clubs always have the option of removing a player from the roster of any of its teams by cutting him. NOTE: The CUT button is located to the far right of each player=s name on the ENYTB roster form, it replaces the previous RELEASE button. IMPORTANT: If a player wants to switch to another team, clubs should NOT use the CUT function to remove the player from the roster of one of their teams. Instead, they should leave him on their roster until he is claimed by a team B or, if they need the roster space, the player can be moved to the team’s DNR list (described below), where he will be treated the same as if he were still on the roster of team A except that he won’t count against the team’s ENYTB roster limit and won’t be eligible to play. If instead, the club CUTS this player, the club would disadvantage itself in two ways: First, the player will become an UFA and will not count against any of the CAPS of the team that picks him up next (team B). This includes CAP1 as well as CAP2/CAP3 (H2H) between team A and team B. Second, the team losing the player, team A, will not get credit for an RFA loss.When a team clicks on the CUT function, they will see the following via a screen message: Per the ENYTB Constitution, player rights reside with club owners, not with teams. To protect the interests of club owners, the website does not allow team managers and coaches to cut players from their roster i.e., CUT is a club level privilege. Thus, to cut a player from your ENYTB roster, team personnel must go through their club rep. Your club rep is “name =” Contact information for your club rep is available at: B> MY TEAM B> Team Account B> Team Profile -----------------------------------------------------------------------------------------------------------------------NOTE: Pete - we will want to add the following logic to the start of the cut function to prevent transactions that should be done as intra-club player transfers from being done via CUT/ADD. ------------------------------------------------------------------------------------------------------------------------ check whether team initiating the transaction is a member of a multi-team club? if no, continue if yes, ask user: Are you cutting this player in order to transfer him to another team in your club?If yes  Terminate CUT and Direct User to Intra-Club Player Transfer Function ENDIf no  Continue. ------------------------------------------------------------------------------------------------------------------------ Club level clicks CUT Function: Did this player ask to be cut?If NO, player = CUT1 = UFA (normal cut).If YES, player = CUT2 = RFA* w team A = None (attempt by family to defeat our caps)The point of defining a RFA sub-classification (RFA*) is twofold:i. To prevent parents from defeating the system of RFA caps by simply pressuring teams into cutting their player in order to obtain an UFA classification. This approach gives the player’s current team an incentive to tell the truth when coerced into cutting a player i.e., by doing so it gets an indirect benefit - an RFA* still counts against the CAP1 of the player’s new team B; and, ii. By taking away all of the potential direct benefits associated with losing an RFA, RFA* eliminates any incentive a team would have to untruthfully classify its cuts as CUT2 i.e., having been requested by player/family (RFA*). SUMMARY – When the player and/or his family requests a cut, the only reason for doing so is to avoid being classified a RFA. Thus, in this situation, by telling the truth, the player’s current team can at least disadvantage its opponents by causing them to have to use CAP1 space to sign the RFA* player. Were a club to give a player a CUT1 when CUT2 was called for, it is simply giving in to the parents and helping them defeat the league’s rules on player movement. While we strongly advise against doing so, there is no rule against it. The league does however, monitor all player transactions.On the other hand, some clubs may be tempted to falsely classify the CUT as a CUT2 to gain an advantage over its opponents (RFA*). Though unethical, there is nothing to stop anyone from doing so other than if this causes the CUT player to be UNable to switch to the team of his choice. Then the club will have to deal with the wrath of the player’s irate parents.Regardless of which CUT function is applied, the player shall not count as an RFA loss for his prior team A, should he be subsequently added to the roster of any team B. Nor will he provide his team A with any CAP2/CAP3 benefit vis a vis the next team that picks him up. So the incentive to cheat has been as small as possible.NOTE: RFA* is the only instance in this entire methodology where a player’s prior status = RFA: Primary w/o being linked to a prior primary team A.Any primary RFA* in period T that is not picked up by any team B by the end of period T+1, shall, at the beginning of period T+2, have his status updated from RFA* to UFA (this logic is same as used for RFA:DNR and will need to be added to the re-initialization routine or run as a separate function each year immediately following re-initialization, your choice). WHOLE TEAM FUNCTIONS – THEIR EFFECT ON PLAYER’S UFA/RFA STATUSi. TEAM DELETE - All teams from the prior year that are not coming back for the current season (failed to re-activate, etc.) are deleted by the League Admin no later than Jan 16. When a team is deleted, all players on its roster shall be automatically CUT and hence, become UFA.ii. TRANSFER TEAM OWNERSHIP TO ANOTHER CLUB – When a club transfers ownership of one or more teams to another club, those teams shall be treated as existing teams (not a new team) for team cap purposes. Its roster and the transaction history for each of its players (prior status) shall follow the team. So, all team CAPS and credits would remain as is. The applicability of the franchise exemption vis a vis teams from other clubs would of course change for all new additions but all current exemptions would be grandfathered as is. ❾ WASHED (OR LAUNDERED) PLAYERS – ILLEGAL PLAYER TRANSACTIONThe system thus far defined could be easily gamed by clubs/teams by simply adding an RFA, cutting him and then re-adding him, all in the current period. EXAMPLE: TEAM WASH------------------------PLAYER TRANSACTIONS – PLAYER A ---------------------------------------------------------------Current Period --------------------------------------------------------YYY CREDITSINITIAL Prior Team = None UFA New Team B = XXX 1ADD1 Prior Team A = XXX RFA New Team B = YYY 0CUT1 Prior Team A = YYY UFA New Team B = None 1ADD2 Prior Team A = YYY UFA New Team B = YYY 1W/o any intervention by the system, any RFA who was added and cut by the same team (team YYY in this case) in the current period would be reclassified an UFA. Thereafter, the same team YYY, or any other team B, could add the same player as an UFA, thereby defeating the entire CAP system i.e., Team YYY ends up with a player that was a RFA on team XXX, w/o using any of its unused cap space. The above example is referred to as a “WASH” because team YYY has literally washed away the player’s RFA status by adding and cutting him in the current period. There are two kinds of washes – the team wash and the club wash. The system could be designed to automatically recognize each kind of wash on the fly and to remedy the situation by creating a synthetic player transaction that undoes the effects of the wash. The problem with such an intervention is that it involves some data manipulation that may not be easy to handle. This approached is presented below as the SYNTHETIC SOLUTION (because the intervention (fix) involves creating a synthetic player transaction to undo the effects of the wash). A more straightforward approach is to intervene in the wash transaction before it is completed i.e., just don’t let it happen in the first place, at least not where it would undermine the integrity of the entire system i.e., primary RFA. A great advantage of this approach is that it would be almost trivial to implement. TEAM WASHESThe anti-wash rule for teams would be as follows: • No CUT shall be allowed for any player that was previously added by the same team in the same current period where that player’s prior status = RFA: Primary.Thus, whenever a team tries to cut a player who is an RFA on their roster, before the system asks the user whether the player/family asked to be cut, the system would check to see if the same player had been previously added as a primary RFA by the same team in the same current period. If so, the transaction would be denied as a team wash i.e., RFA: Primary player can’t be added and cut (CUT1 or CUT2) by the same team in the current period. LOGIC FOR IDENTIFYING/PREVENTING A TEAM WASH:Whenever a team requests to CUT any player whose prior status = RFA: Primary Was player in this CUT transaction also in prior ADD transaction in the current period? If No, Not A Wash, ENDIf Yes, CUT = WASH (highlighted in yellow above). Screen message to user:“This player transaction is denied. You are attempting to cut a primary RFA that was added to your roster in the current period. That is an illegal roster operation, defined as a “team wash”. If you are trying to cut this player to transfer him to another team in your club, please use the Intra-club Player Transfer Function for that purpose. If you need assistance regarding this player transaction, please contact the league administrator.”CLUB WASHESNot all washes are team washes i.e., sometimes a team will cut a primary RFA signed in the current or previous period so that another team owned by the same club can add the player as an UFA. This is defined as a club wash and is illegal because the RFA, by virtue of being cut, is reclassified as an UFA and the 2nd team in this transaction would be able to add him scott free. Thus, any time a team asks to add an UFA in the current period, we must verify that the player was not CUT as a primary RFA by a team from the same club in the current period. LOGIC FOR IDENTIFYING/PREVENTING A CLUB WASHFollowing an ADD PLAYER request for any UFA: Was the player in this ADD transaction also the subject of a CUT transaction in the current period? If NO, not a club wash. END If YES, continue  In prior CUT TRANSACTION, was player’s prior status = RFA: Primary? If No, Not A Club Wash, ENDIf Yes, continue Is New Team B in this ADD transaction owned by the same club as current team in prior CUT transaction? if No, Not a Club Wash, END. if yes, CUT/ADD = CLUB WASH, continue  ABORT PLAYER ADDScreen message to user:“This player transaction has been identified as an illegal roster operation, defined as a “club wash”. You are attempting to add a player that was cut by another team in your club in the current period and whose prior status = RFA: primary. This player can be transferred between teams owned by the same club via the Intra-club Player Transfer Function. If that was your intention, please click here and the player shall be restored to his former team’s roster with the same prior status as he originally had i.e., RFA: PRIMARY: team A = restore.” END  ❿ TRANSFERRING PLAYERS TO NON-ROSTER LISTSThe website provides ENYTB clubs/teams several options for unilaterally removing a player from its ENYTB roster. One, the CUT, has already been described in section 8. The CUT is a permanent roster move, relinquishing all club rights to the player. (The player is removed from the team roster and is reclassified as an UFA or RFA*.) There are other several other “special” situations that routinely arise during a season where the club does not want to keep the player on its roster but it does not want to surrender any of its club rights e.g., entitlement to RFA loss credit, used credit for new team B (CAP1, CAP2 and CAP3) and/or it does not want the player to be able to play for another league member until the matter that created the situation is resolved. For example, where a player either balks at returning to his team or simply does not communicate with his team, e.g., moves away, gives up the game. Or, where a player is significantly injured and unable to play again in the current period and the team needs the roster space to add a replacement but does not want to give up its RFA entitlement by cutting the player. Or, where a non-returning player owes his former team money and/or a uniform. For each of these special situations, an option other than CUT is available. The RunMyLeague.com website used by ENYTB provides each team with a set of three non-roster lists for these special situations. Each is used in conjunction with the team’s ENYTB roster. They are:(a) Did Not Report list;(b) Injured Reserve list; and,(c) League Ineligible list. RULES COMMON TO ALL THREE LISTS:• Managers and coaches can transfer players between their ENYTB roster and non-roster lists w/o aid of their club rep (team-level functions); • Players can only appear on one non-roster list at a time;• When a player is added to any non-roster list, he is automatically removed from the team=s ENYTB roster;• A team can restore a player at any time from any non-roster list to its ENYTB roster;• A player on IR or IE is 100% protected from any player transaction initiated by another ENYTB team;• A player on DNR is eligible for a player transaction involving a switch to another league team but his current team will receive all the potential benefits associated with losing an RFA: Primary to another league team; and,• While a player is on any of these lists, he does not count towards the team=s ENYTB roster limit.Each list also has significant individual advantages, as described next: Did Not Report List (DNR):When a player does not report, the DNR list is a much better option than just cutting the player. Were he cut instead, the team would lose all of the benefits associated with losing a RFA should the player get added to the roster of another team B e.g., gaining credit for a RFA loss as well as forcing another team B to use its various RFA credits to add the player. • Only primary players can be moved to the ADid Not Report List@. Thus, by definition, all DNR players are primary RFA;• For purposes of roster protection, there is no distinction between a player on a team’s DNR list or its ENYTB roster i.e., to be added to the roster of another team B as primary, the DNR player is subject to all of the same restrictions as an RFA appearing on the team’s ENYTB roster;• Players may be kept on a team=s DNR for a maximum of two consecutive years;• Should circumstances change at any time during those two years, teams have the capability to restore players from DNR to their ENYTB roster; and,• At the conclusion of two years on a DNR list, players shall be automatically cut from the team i.e., they shall be made UFA with primary team A = none. (This needs to be included in re-initialization routine or a separate routine to clean data immediately following initialization.)Injured Reserve List (IR):To be placed on IR the player must be significantly injured. The league may require the team to produce a doctor’s statement that the player is unable to play baseball for the remainder of the season.All IR players shall be automatically restored to his team’s active roster when it is first activated for ENYTB player the following season. If the restoration of IR players results in the number of players on the roster exceeding the team=s ENYTB roster limit, the club and team shall be notified by auto-email that it has until Feb 1 to attain compliance with the ENYTB roster limit. If the team fails to meet this requirement, the website shall limit the club/team=s access to only its roster page until compliance is attained. • Once placed on IR, the player is ineligible to play for any ENYTB team in the same season, including on a secondary basis.• Only primary players can be placed on a team=s IR list. Thus, by definition, all IR players are primary RFA;• Once placed on IR, a player can’t return to the team’s ENYTB roster in the same season, including post-season.• While on IR, a player shall not be eligible to be added to the roster of another team, either as primary or secondary. Player also shall not be eligible for transfer to another team owned by the same club. Ineligible List (IE):• This is a team level function i.e., managers and coaches can make these moves w/o aid of their club rep;• To be placed on this list the player must owe their team money, uniform, etc.• Unlike the other non-roster lists, both primary and secondary players are eligible for placement on a team’s IE list;• Any player appearing on this list shall be ineligible to be added to the roster of another team as primary or secondary until the indebtedness is fully satisfied and the team removes the player from list;• Once the player/family has satisfied its indebtedness, the player can be removed from IE in either of two ways:o By moving him to the team=s DNR list (to make him eligible for movement while preserving potential benefits associated with RFA losses); or,o By moving him back to the team=s active ENYTB roster (where the player can be cut or restored as an active player. • A player can be moved on/off IE at any time.• A player can remain on a team=s IE list for the life of the team.NOTE: We need a way to keep ineligible players ineligible after their team is terminated or discontinued. If the club owned an ongoing team that the player was age-eligible for, one possibility would be use the intra-club player transfer function , before deleting the discontinued team, to move the player to the ongoing team and then to that team’s IE. But, if there is no age-eligible ongoing team, this solution is not universal. An alternative approach would be to mark/unmark a player’s database record as IE when a team moves a player on their IE list. This designation would be turned off if/when a player is removed from IE. On the other hand, if the team was deleted while the player was still on IE, his database record would continue to show IE, making him ineligible to be added to any team’s roster as primary or secondary. This way they would remain IE after their team was deleted. Of course, you would need to give me a toggle switch on the player’s database record to turn off the IE designation were the player to subsequently satisfy his indebtedness. A third approach would be to create a 3rd status for teams e.g., active, inactive and dead. Dead teams could be carried for as long as the club remains active. DEAD TEAM would be just like delete except that it would maintain the basic team ID along with its League Ineligible List and a blank roster. All players and coaches would be unlinked except for those still on the League Ineligible list. When players paid their indebtedness, they could be moved to the roster of the dead team and cut. Or, we could have a cut function on the League Ineligible list that only ADMIN has access to. Then you could eliminate the roster altogether. This seems like the most promising approach. ⓫ INTRA-CLUB PLAYER TRANSFER FUNCTIONThis is a new function, available at the club level only. It is designed to allow clubs to transfer primary players between teams owned by that same club.NOTE: If clubs were to use the CUT/ADD functions instead, the system would identify that series of operations as an illegal operation = CLUB WASH. This is done to prevent clubs from adding an RFA: Primary: team A = X to one of their teams that had RFA credits, then cut the same player in the current period and add him as a newly scrubbed UFA to any of their other teams, thereby defeating the effects of the team caps. For this reason, the only way for clubs to move RFA: PRIMARY players between teams they own is by using this intra-club player transfer function. This tool can be used for UFA: primary players as well. (Unlike RFA: PRIMARY, UFA can be transferred via the CUT/ADD functions because they are not subject to team caps i.e., player washing is not a concern.) (1) NOT APPLIED TO TRANSFER OF SECONDARY PLAYERSIf a club attempts to transfer a secondary player: give user following screen message:“The intra-club player transfer function is applicable to primary players only. Player movement on the secondary level is not subject to team caps and therefore can and must be handled via the usual CUT/ADD process. USER INSTRUCTIONS FOR CHANGING TEAMS AT SECONDARY LEVEL:(A) If the “transfer from” and “transfer to” teams are in the same age division:• Cut the player from the “transfer from” team and,• Add same player to roster of “transfer to” team (as secondary) in usual fashion via ADD PLAYER. (B) If the “transfer from” and “transfer to” teams are not in the same age division:• Add player to “transfer to” team (as secondary) in usual fashion via ADD PLAYER.” (2) APPLY TO TRANSFER OF PRIMARY PLAYERS ONLYAny player acquired either as an UFA: Primary or an RFA: Primary shall be given a TRANSFER button (club level) that appears next to the player’s name on the team’s ENYTB roster.i. Club user goes to team = “transfer from” and clicks TRANSFER button for selected player;ii. Club user selects team = “transfer to” from list of age-eligible teams from same club.(A) If the player’s prior status on team = “transfer from” = UFA: o TRANSFER  UFA: Primary player is removed from roster of “transfer from” team and added to roster of “transfer to” team, with prior status = UFA.Print on-screen message to user: Transfer of “player name =” from “team name =” to “team name =” has been completed.NOTE: Since UFA are not subject to team CAPS, they also can be “transferred” via the usual CUT/ADD functions w/o being identified as a club wash.(B) If the player’s prior status = RFA: Primary and team A = X when added to the “transfer from” team: o TRANSFER  RFA: Primary player is removed from “transfer from” team and added to roster of “transfer to” team as RFA: Primary and team A = X if and only if the “transfer to” team has sufficient unused cap space for player transaction (transfer) to be accepted.  TEST1: Does team B have unused CAP1 > 0?If NO, user is advised via screen message that “Transfer of “player name =” was not permitted because unused CAP1 for “team B name =” = 0. END If YES, continue Is player’s current status year of origin on roster of “transfer from” team = current period? If NO, skip to TEST3 If YES, continueTEST2: Does team B have unused CAP2 > 0 vis a vis player=s prior primary team A?If NO, user is advised via screen message that “Transfer of “player name =” was not permitted because unused CAP2 for “team B name =” vis a vis player’s “prior team A name =” = 0. END If YES, continue TEST3: Does team B have unused CAP3 > 0 vis a vis player=s prior status primary team X? If YES, transfer = OK.  Remove player from roster of “transfer from” team and add to roster of “transfer to” team as RFA: Primary with same prior team A = X. Inform user: Transfer of “player name =” from “team name =” to “team name =” has been completed. ENDIMPORTANT: For all RFA: Primary TRANSFERS  keep current status year of origin unchanged from “transfer from” team. This prevents prior team A from getting credit for another RFA loss via CAP2. If current status year of origin = current period, “transfer from” team will get credit for RFA loss (and should).If NO, giver user screen message: “Transfer of “player name =” not permitted because unused CAP3 for “team B name =” vis a vis player’s “prior team A name =” = 0. END---------------------------------------------------------------------------------------------------------------------------------This cap checking algorithm prevents clubs/teams from using the intra-club player transfer function to game the system. For example, w/o the cap checking algorithm, clubs could acquire an RFA: Primary player with one team (via that team’s unused RFA credits) and then transfer the same player to another team it owns as though the player was an UFA i.e., TRANSFER WASHES. End result: neither team has used any CAP credits yet RFA; Primary player is on roster of “transfer to” team.NOTE: Before actually transferring a RFA: Primary, we will want to notify the user: “team B name =” has sufficient RFA credits for this transfer.Do you want to transfer “player name =” to “team B name =”?If NO, report “Transfer of “player name =” terminated by user.” ENDIf YES, perform TRANSFER and report: “Transfer of “player name =” is complete.”Otherwise, the user may be oblivious to the fact RFA:Primary transfers involve the use of CAP credits for the target team. NOTE: Transferred player=s password will need to be reset for new team B. This will be true of all player transactions where player changes teams. ⓬ OVERVIEW FROM PARENT/PLAYER PERSPECTIVE, INCLUDING REAL TIME TOOLS THAT DETERMINE TEAM & PLAYER SPECIFIC CAP ELIGIBILITYUnder the new system of player movement, players are always free to switch to a different team, provided the window of eligibility for RFA movement is still open (from early NOV to MAR 1 each year). PARENTS IMPORTANT: Parents need to be aware that a team’s RFA cap may prevent a player from joining the team of his first choice i.e., your player may want to play for team B1 and team B1 may even want to add your player to their ENYTB roster, but they may be prevented from doing so by their cap constraints (CAP1 or CAP2/CAP3 defined with respect to team B and the player’s current team (team A), defined in section 2.)When the website determines that an RFA does not fit under one or more cap constraints for a team B, the prospective player transaction is rejected. When a player transaction is unsuccessful, the player’s current league status is unaffected i.e., if the player was on the roster of team A prior to an attempted transaction, and the player transaction fails, the player will still be on the roster of team A.Releases per se no longer have any purpose within ENYTB. Instead, players simply “switch” teams.In order to switch teams under the new system, a player would contact the team or teams he is interested in playing for and deter