In memory of my sanity~

    0x80040400: QuickBooks found an error when parsing the provided XML text stream.

Never use instance variables across methods that you are not explicitly calling. The qbwc gem creates a new instance for every single method call.
If you need to persist Information use either data[(foo)] (Please keep data as a hash unless you are a masochist) or make a new instance of the respective entity action class to find a value.

• Quickbooks Integration
  • Most Important Information
  • Index
  • A Note to Everyone in IT
  • Dictionary
  • Structure
  • Current Progress
  • TODO
  • Important Variables
    • Entity Class
  • Logic Flow
    • Example
  • Changes Made During Install
    • Directories/Files
    • Migrations
    • QBWC Other Changes

I just want to say to say thank you for being accomodating of all the weirdness involved with this project. While I may be a bit sarcastic/etc throughout parts of this project, it is mainly caused by frusteration and I don't want it to obscure how gratful I am to have gotten to work on this. I have been going through a rough patch for a little while now, and coming in each day to work on this has been something I would look forward to every night. It has truly been a pleasure. - Kyle

QBWC - The qbwc gem that this project is centered around.
QBW - The QuickBooks Webconnecter ( I didn't come up with these - thank Intuit )
Qb - Quickbooks
QbC, QbI, QbP - Qb + [Company, Invoice, Payment] and so on.
qbc - Same as QbC but different use case. (I.E. Instance instead of Class usually, also used as a method to create an instance)
qbc_i - qb company's invoice
qbp_ip_i - qb payment's invoice_payment's invoice ( It just gets worse. Basically just read it in whatever way makes it obey the plurality it should be.)
** Just as a note these chained names are mainly found deeper within the action classes.

• QBWC::Worker
  • Main Class < QBWC::Worker
    • Entity Classes < Main Class (includes respective entity actions module)
    • Entity Actions Modules
      • Action Classes < Entity Classes
      • Action Modules (These create way too much confusion.)

• QBWC::Worker
  • QbWorker (< QBWC::Worker)
    • includes Qb::[Companies, Invoices, Payments]
  • Qb
    • QbC (< QbWorker)
    • Companies
      • Add
      • Mod
      • Del
      • Query
    • QbI
    • Invoices (Most actions depend on Company)
      • Add
      • Mod
      • Del
      • Query
      • Void
    • QbP
    • Payments (Most actions depend on Company && Invoice)
      • Add
      • Mod
      • Del
      • Query
      • Void

• Change all uses of &. to the longer version with && (I can not express how much pain this will bring me. This goes against every fiber of my being.)
• Check if this can be used with the qbwc ~> 1.0.0 as a base since that should allow usage of ruby 2.2.2
• Contemplate the morality/ethical concerns of backporting this for ruby 2.2.2 when it was depreciated in 2018. I can only imagine the sheer quantity of security issues involved with using such an old version of ruby.

@qb_entity = String; Qb name for the entity. (CamelCase)
@t2_entity = Class; The T2 Model's Class
@t2_instance = Object; An instance of t2_entity found using a supplied ID.

• Same for every entity mostly. Only difference is Company doesn't have a Void action.
• For readability I am going to omit any intermediate logic I can. This is just to get an idea of what certain actions will lead to eventually. Assume "~>" encompasses a couple steps.

new_invoice = Invoice.new(paid_amount: 1000).save ~> Qb::Invoices::Add.act(new_invoice)
Qb::Invoices::Add.act(new_invoice) ~> QBWC.add_job(...) # Enters an entry into qbwc_jobs
# Next step is prompted whenever QWC runs and sends a request to a predetermined link.
(QBWC Gem) Qb::Invoices::Add.new.should_run?(job, session, data) ~>
(T2) Qb::Invoices::Add:Object.should_run?(...) ~> (calls super do ... end or default)
(T2) Qb::QbI:Object.should_run?(...) ~> (calls super do ... end or default)
(T2) QbWorker:Object.should_run?(...) ~> (yields or default)
(QBWC Gem) QBWC::Worker:Object.should_run?(...) ~>

This pattern is repeated in the following methods in the above mentioned classes:

• initialize(data= nil) (note- qbwc doesn't call new with parameters.)
• should_run?(job, session, data)
• requests(job, session, data)
• handle_response(response, session, job, request, data) (In that order, for whatever reason)

The reason that all of these call super is that at the top of the chain is QbWorker which initializes @t2_instance in every method call. This allows us to avoid manually writing out 20 find_by's. Additionally it allows guaranteeing handle_response always deletes the job on completion (assuming it doesn't error out).

I'm going to do my best to add everything here, but considering this needs to be ported to rails 4 it is liable to change.

• Directories/Files

  (In ~/app/)
  Format: directory - [file, ...] (.rb not being shown)

  • quickbooks - [qb_worker, qb_hook, grammar, README]
    • qb - [qb_c, qb_i, qb_p]
      • companies - [add, mod, del, query, void(just contains nil)]
      • invoices - [add, mod, del, query, void]
      • payments - [add, mod, del, query, void]

• Migrations (In ~/db/migrate/)

  • add_qb_id_to_payments.rb
  • add_qb_id_to_invoice_lines.rb
  • create_qbwc_jobs.rb
  • create_qbwc_sessions.rb
  • index_qbwc_jobs.rb
  • change_request_index.rb
  • session_pending_jobs_text.rb

• QBWC Other Changes

  • Adds an initializer
  • Adds a controller
  • Adds 3 routes