* Complex replacements might be easier by passing an array into the ActiveRecord constructor setting attributes. 

             * With `ItemDiscount`, it was initialized with `new ItemDiscount(0, $lineItemId)` to create a new `ItemDiscount` based on a previous `LineItem`. I solved this with: 

             ``` php

                 'discounted_line_item_id => $lineItem->getLineItemId(),

             ]);

             ```

 5. I elimitated code that would set improper data to an empty string in order to have it remain `null`. (e.g. `check_deposit_date` was set to a date if it was valid, else ''. I removed the else and chose to ignore any assignment. It simply stays `null`.

 6. Look through CRUD methods implemented in the class (e.g. `save()`, `delete()`, etc). Remove them.

     * `PaymentTransaction::save()` was a little more complicated than a simple update of attributes in the database. It also called upon invoice to update its balance.

     * `PaymentTransaction::save()` also set the `created` attribute. I originally put a hook to set `created` after create, but that overwrote things set in the Factory. Plus there is a default value in the database, so it should be good to leave out.

 7. If the class is not directly inhereting from `Model` (for instace, `ItemDiscount`) look for refernces to the parent's entities and make sure those are explicitly made in associations (`has_one`, `has_many`, etc.)

 ## Notes

 -----

 6. Look through CRUD methods implemented in the class (e.g. `save()`, `delete()`, etc). Remove them.

     * `PaymentTransaction::save()` was a little more complicated than a simple update of attributes in the database. It also called upon invoice to update its balance.

     * `PaymentTransaction::save()` also set the `created` attribute. I originally put a hook to set `created` after create, but that overwrote things set in the Factory. Plus there is a default value in the database, so it should be good to leave out.

 ## Notes

 -----

 6. Look through CRUD methods implemented in the class (e.g. `save()`, `delete()`, etc). Remove them.

     * `PaymentTransaction::save()` was a little more complicated than a simple update of attributes in the database. It also called upon invoice to update its balance.

     * `PaymentTransaction::save()` also set the `created` attribute. I originally put a hook to set `created` after create, but that overwrote things set in the Factory. Plus there is a default value in the database, so it should be good to leave out.

 ## Notes

 -----

     * This will break lots of stuff. 

         * In tests, I would recommend taking the constructor and substituting it for a Factory object with the parameters set via FactoryMuffin.

         * It is probably common that it was called with an existing id in order to load the record. This can be replaced with the ActiveRecord::find($id) method.

 5. I elimitated code that would set improper data to an empty string in order to have it remain `null`. (e.g. `check_deposit_date` was set to a date if it was valid, else ''. I removed the else and chose to ignore any assignment. It simply stays `null`.

 6. Look through CRUD methods implemented in the class (e.g. `save()`, `delete()`, etc). Remove them.

     * `PaymentTransaction::save()` was a little more complicated than a simple update of attributes in the database. It also called upon invoice to update its balance.

         * My suggestion would be to keep all of the getters and setters, at least at this point. This will maintain compatability with existing code. I also personally like the getters and setters.    

     * The next thing I did was run the tests. This caught variables in the FactoryMuffin object that were mis-named. (e.g. `PaymentTransaction` factory used `invoiceId` and needed to be changed to `invoice_id`. This is more than just in the FactoryMuffin definition, because there was some custom construction of these factories in various test suites.)

 4. Remove any default constructors (including constructors where all parameters have default values assigned.

 5. I elimitated code that would set improper data to an empty string in order to have it remain `null`. (e.g. `check_deposit_date` was set to a date if it was valid, else ''. I removed the else and chose to ignore any assignment. It simply stays `null`.

 6. Look through CRUD methods implemented in the class (e.g. `save()`, `delete()`, etc). Remove them.

     * `PaymentTransaction::save()` was a little more complicated than a simple update of attributes in the database. It also called upon invoice to update its balance.