//////////////////////////////////////////
Eric and Brandon talking on 10/30/18

- assuming a good setup has already taken place...
	- use or don't use
	- if use, what, or which one, or multi?
	- where does this happen? I would recommend that we setup some values in the main session cart or ecommerce cart
	- we have internal (secure environment) and also ecommerce (external) and we have API (socket connections)
	- we have the control based on the master pieces that we open... (database controlled)

- transactions...
	- it should actually happen and hit the database on the same page or area as the cart transitioning from session to real database
	- we will have both line items on an invoice as well as possible custom payment options (with logic to back it up)
		- leaning more towards the custom payment options.
		- Also as a note, we were talking about money types (id's) 1-200 being reserved for system controlled and
			money type id's 200+ would be used for custom money types (corp specific).
			- there is a built-in table update for this table already... it may need to be updated to handle just the system money types.
	- we were talking about allowing the cart to look-up and search the database for options (what do i have and what is available)
		- we were also talking about how the actual write (insert and/or update) will happen in the submit page where everything else gets converted.
		- as we were talking about it, we would like to de-couple the holding container from the cart (look it up each time because it could change...)
	- there is a possibility that the user has an open live cart and an open ecommerce cart...
		- we don't want to assume that both get equal access to the rewards and/or gift cards. just covering our basis.
		- timing of what really happens and where the rubber meets the road.
		- think of a shared gift card... who gets to work off what part and when... not owened by a single person.
	- possible option... treat some of these things like taxes and recalc on the fly. We want to do this and recalc on the fly.
	- the other option is to show existing (real values) and then make the transaction happen right at the end.
		Make sure and look it up before using it (final check).

- scenarios
	- rewards/loyalty points
		- setup
			- corp-specific, allow a few renames, chaning values, restoring back to defaults
			- corp to client assignments - opt in/out
			- payment type and/or item setup (leaning more towards the custom payment types - see notes on money types above)
		- earn
			- what about opt in/out for certain clients (are there entry requirements? corp-assignments, etc.)
			- based off of rules
			- most of the work is driven from the cart and actually posted/committed after the fact (committing and submitting to the database)
			- what about edits (after the fact changes) and/or voids on invoices (clean-up processes)
				- we know that these after the fact changes... could create negative account balances
		- use
			- pre-use (how many are available - look-up of known balance)
			- when do we check this? 1st - check what is available (semi unknown - not locked in - de-couple but show in the cart).
				- 2nd - check right before final processing (before any database transactions). Return them, if needed, back to the cart.
				- 3rd - Passed all other checks and we are going through with it (final/final).
			- record transaction in the database
			- payment type and logic (may require some cross checking and rolling things in/out - variable or questions)
			- possible line item in the cart upon checkout
		- reporting
			- all able to view at the customer level
			- only certain people may see all customer accounts
			- if tied to a balance sheet item, show summaries with drill-downs to more groups and details. brandon can help with this.
			- liability reports - what is still out there and has not yet been claimed and/or used.
			- other reporting such as general stats, usage, percentages, and overviews
			- payment names and/or money type names - still in question
				- we could go with standards and then mask the names or we could go with straight custom (leaning towards fixed money types)
		- manual overrides/special
			- only permissioned persons may make manual entries (we need a manual entry form that allows for both adds and edits and ties out to history)
		- histories
			- no history if used normally
			- yes, add a hisotry if any manual interactions (add/edits/voids/deletes/transfers/etc.)
				- no note flag on adds (just normal descriptions), add - void on voids, add - modified on changes or edits.
			- no edits on history - we may need a report that shows the histories
		- cautions
			- sharing and timing (we only want to use and give out what really exists)
			- exclusions (may be handled up at the rule level)
			- expirations (do they run out or become inactive)
			- stopping or discontinuing something - what happens then... technically, there are data and transactions but the company decides no go.
			- future to do lists
				- tie to dates and times (talk to Josh - he has some similar stuff in his discount engine and general discount rules).
			- remember ecommerce
			- remember API sockets and external land
			- what happens, if a new master rule is added... how does that play in?

	- gift cards/certificates
		- setup
		- earn
		- use
		- reporting
		- manual overrides/special
		- histories
		- cautions
	- in-store credit
		- setup
		- earn
		- use
		- reporting
		- manual overrides/special
		- histories
		- cautions
	- lunch cards
		- setup
		- earn
		- use
		- reporting
		- manual overrides/special
		- histories
		- cautions
	- other
		- setup
		- earn
		- use
		- reporting
		- manual overrides/special
		- histories
		- cautions



/////////////////////////////////////////////////////////
new notes on 11/19/18


- new cart structure - on purpose, de-couple from the main cart and look-up each time
	- known buckets - points earned, ratios, points spent and/or redeemed, math, available, etc.
	- question on multi users interacting with the same client (possible - things could be changing while data is in the cart - think of a shared gift card)

- Eric would like to run everything off of a real invoice number (that way we get info from the secure cart, ecommerce, after the fact invoices, API sockets, etc.)
	- Everything that creates an invoice, gets the new logic for loyalty points.

- We need to spread out the logic to do the transactions for special accounts in key places where invoices are created and/or line items are added and/or updated. Also, remember voids and/or deletes (removing line items).

- side note... if we are adding some new visual pieces into the view cart pages, there are 5 known view cart pages. Just a heads up.

- Talking processes...
	- start with the master setup
		- add a new one
		- add new rules
		- add a new payment type
	- setup the corp level
		- naming and rules
	- corp-wide payment display options
	- how do we display it in the cart?
	- if they click it, in the cart, how do I display it?
	- how do I do the manual entry (if they have the permission)?
	- can I view it from a customer or vendor record (conditional)
	/// stopped here for the day