/
Build LDO From Revenue LDO290

Build LDO From Revenue LDO290

Search the IFS Excalibur Wiki

Use this process to convert Revenue Decks into Land Division Orders. You can set up Revenue Decks that need to be deflated with individual Conversion Tables in Revenue Conversion - LDO198. Use the Conversion Table to describe the breakdown of interest for all working interest owners, including those who are not on the Revenue Deck. Enter working interest owners who are not on the Revenue Deck as non-receiving owners. For Oklahoma wells, enter Proportionate Production Interest (PPI) percent to be used for communitizing royalty burdens on the Conversion Table for all working interest owners, including non-receiving owners (who are not on the Revenue Deck).

The calculations performed on revenue interests to convert to LDO are as follows:

Gross Working Interest (GWI)

This only applies to working interest-type owners:

  • If there is no Conversion Table set up for the Deck, the program assigns GWI without applying any deflation factor.

  • If there is a Conversion Table set up for the Deck, the program assigns GWI from the Conversion Table, instead of from the Deck, for each working interest owner, whether or not the owner is actually on the corresponding Revenue Deck.



Net Revenue Interest (NRI)

This is applied to owners of all interest types:

  • If there is no Conversion Table set up for the Deck, the program assigns NRI from the Deck without applying any deflation factor.

  • If this is not an Oklahoma well and there is a Conversion Table set up for the Revenue Deck, the program assigns owners of all interest types who are on the Revenue Deck NRI equal to the interest on the Deck times the deflation factor from the Conversion Table. The program assigns Non-receiving owners, who are on the Conversion Table but not on the Deck, NRI equal to their GWI from the Conversion Table. If this is an Oklahoma well with a corresponding Conversion Table, the program calculates NRI differently for each interest type. The program assigns Receiving-type working interest owners (who are a part of the Revenue Deck), and overriding royalty interest-type owners NRI equal to the interest from the Deck times the Deflation Factor on the Conversion Table. The program assigns straight royalty interest-type owners NRI from the Deck without application of the Conversion Table deflation factor. The program assigns non-receiving working interest owners (not included on the Revenue Deck) NRI equal to their PPI interest from the Conversion Table times the factor obtained from taking one minus the sum of interests for straight royalty owners.



Working Interest Burdens

The program distributes royalty interests for each working interest owner in the following way:

  • If there is no Conversion Table set up for the Revenue Deck, the program assigns burdens to working interest owners from each overriding and straight royalty interest owner as the working interest owner's GWI times the royalty interest owner's NRI from the Revenue Deck.

  • If this is not an Oklahoma well and there is a Conversion Table set up for the Revenue Deck, the program assigns burdens only to the owners from the Conversion Table who are specified to be assigned burdens. These will normally be the receiving owners from the Revenue Deck. The program calculates the burdens as the working interest owner's GWI times the royalty interest owner's NRI, and then proportions them upwards to account for the owners from the Conversion Table who are not assigned burdens-- i.e. each burden interest is divided by the sum of GWI interests for assign-burden owners.

  • If this is an Oklahoma well and there is a Conversion Table set up for the Revenue Deck, the program normally assigns burdens to all owners, receiving and non-receiving, (unless otherwise specified in the Conversion Table). If there are one or more overriding royalty interest owners, only one working interest owner is allowed for the conversion to be successful (otherwise, an error message is printed, and the conversion is not performed). Then the program assigns overriding royalty burdens straight to the working interest owner as the override interest owner's deflated NRI. Straight royalty interest owners burden a working interest owner by the difference between the working interest owner's GWI and NRI, multiplied by each royalty interest owner's NRI, and then proportioned upward to the scale of the total of royalty interest owner interests on the Revenue Deck, i.e. each burden is divided by that total of royalty interest owner interests (royalty interest owner NRIs are not deflated).

You can choose the Audit Page Print option to see a detailed description of all the calculations performed on each deck processed.



Concerns Before Processing

  • Security - A company anticipating building all of their Division Order Master (DOM) entries through managed LDO_MASTER (LDOM) items needs to address the security of their distribution decks (both from the LDOM side and from the converted DOM side). This issue is not part of placing them onto the LDOM, but rather the converse: What to do about changes and who makes them with Land Division Orders and then pipes them back through Revenue.

  • Management - The process of executing Build/Update Revenue DOIs - LDO350, needs to be controlled. This utility should only be processed once a month. Paradigm recommends that either the Revenue Manager or the Title Manager execute this process. It should be on a scheduled timeline so that last-minute changes can be made first in Land Division Orders through DOI Mass Change - LDO300, followed by the Build/Update Revenue DOIs - LDO350, before the next Revenue processing run. Further, Build LDO from Revenue (LDO290), should be controlled by the System Administrator for the company. This ensures that the process is utilized in a controlled manner.



Files Updated

  • LDO_MASTER (LDOM)

  • LDO_LT_MASTER (LDOLTM)

  • LDO_TRACT_DETAIL (LDOTD)

  • LDO_OWNER_REMARKS (LDOOR)

  • LDO_LT_MASTER_XREF (LDOLTX)

  • DOI.OWNER.INDEX (DOIX)



Miscellaneous

  • Check to see if any of the files listed above need to be resized prior to running.

  • Read the entire documentation before running.



Error Messages

  • The program checks to see if the Division Order Master has a DMCC Effective Date. If it does, Build/Update Revenue DOIs - LDO350 created the Division Order and, therefore, LDO items should already exist. The system prints the following ERROR message, and skips the processing of the division order:

"DIVISION_ORDER_MASTER Item "XXX" was built using LDO (LDO350). Not Processed."

  • If the program tries to create LDO items that were already created from the selected division order, the system prints an ERROR message and skips the processing of the division order:

"LDO items already created from "XXX". Not processed."

Note: At the time LDO items are created (using this program), a Transferred Status flag is set. Since the Division Order exists, the LDO item has essentially already been transferred to Revenue and, therefore, cannot be modified using Build Division of Interest - LDO110.

  • If you want to recreate the LDO item, you need to edit the LDOM and remove the T from AMC17 of the LDOM, call up the well/product/effective date in Build Division of Interest - LDO110 and delete the existing item. You also need to remove the LDOM reference from the DIVISION_ORDER_MASTER from AMC29 using the editor. You can then re-select the division order for reprocessing.

  • If the program tries to create LDO items that already exist, but are not from the creation of the selected division order, the system prints an ERROR message and skips the processing of the division order:

Dup Div Order. LDOM already built from "XXX". Not processed.

  • If the program tries to create LDO items that already exist, but there is no Division Order reference on the LDO_MASTER, the LDOM was already created in LDO using Build Division of Interest - LDO110. The program prints the following ERROR message and skips the processing of the Division Order:

LDOM.ITEM already exists. Not processed.

  • If a Division Order has been permanently expired, the program prints the following ERROR message and skips the processing of the division order.

DOM Permanently expired. Not processed.

  • If a Division Order has an expiration date, the program still creates the LDO items and prints the following message:

DOM expired "XX/XX/XX", yet updating LDO.

Note: This is not an ERROR message - the LDO items are still created.

  • This program should create a new LDO_TRACT_DETAIL record for every LDO_MASTER record. If the program finds an existing LDO_TRACT_DETAIL record, it prints the following ERROR message and skips the processing of the Division Order:

LDO_TRACT_DETAIL Item "X*X*X*X*XXXX" already exists. Not processed.

It will create all LDOM records unless a WI Owner is not found, then it prints the following ERROR message and skips the processing of the Division Order:

CO WELL PRODUCT EFF.DATE XXX DOM missing WI owner. Not processed.

  • If a Revenue DOM owner does not have a Working Interest Owner, the system prints an ERROR message and skips the processing of this Division Order.

 

Technical Information

Special LDO290 processing notes that involve the client support rep and the editor:

1. If you should build an LDO_MASTER record that you did not mean to build, you can work with a IFS Excalibur support representative to delete the record.

If you want to rerun LDO290 for a given DOM:

Edit the built LDOM and remove the T from AMC 17 (STATUS) and remove the DOM reference from AMC 14 (DIV_ID). Next call up the LDOM (co/well/product/effective date) in Build Division of Interest - LDO110, and delete the existing item.

Remove the LDOM reference from the DIVISION_ORDER_MASTER from AMCs 29 (BUILT_LDOM_ID) and 31 (LDOM_ID) using the editor.

2. There is a feature with LDO290 to build an LDOM one day greater than the DOM's effective date. Basically, there is a hard-coded flag in the program that a IFS Excalibur representative can set for you to accomplish this feature (the current default is set to inhibit this feature).

If this flag (NEW.EFF.DT.FLAG) is set then If LDO290 tries to build an LDOM for a given effective date and that LDOM already exists, the program continues to add one to the effective date until it is possible to build a NEW LDOM.

If this flag (NEW.EFF.DT.FLAG) is not set (default) then If LDO290 tries to build an LDOM for a given effective date and that LDOM already exists, the program generates an error message stating that an LDOM already exists and there is no LDOM created.


3. LDOM needs to have a different DOM ref than the one being processed through LDO290.


Copyright© 2024 IFS AB. Copying prohibited. All rights reserved.