////////////////////////////////////////// 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 //////////////////////////////////////////////////////////////// new notes on 11/27/18 - possible problems with cross-corp customers and different corps sharing rewards and loyalty points. Eric has been using the customer cell phone number. We could also use special id's and/or barcodes. - The question here (cross-corp special accounts) deals with small mini and/or orphan accounts. We briefly talked about having master lists of users, maybe customers, etc. We talked about ideas of allowing those users and customers to be contolled at a high level and then cascaded and/or duplicated down to the levels where they are needed. - Eric had some questions about grouping corporations and locations in order to share customers. This gets really deep. Our work around to this is using some unique value and then finding and filtering according to that. This could be a custom code nightmare. We may also be able to use the external_alternate_id (varchar 50 on the customers table) or we could use some sort of application flex grid to do some cross-corp mapping (customer a in this corp is actually customer q in this other corp). - There are some problems with the cross-corp matching and bad data entry. People love to go fast and may enter similar info (bad data) for multiple customers. - It may go back to corp assignments to individual accounts. We could then use a data matching process in the background. - We may need a higher joiner table that allows corps to be joined together. This currently doesn't exist, but it would allow corps to be stacked vs just stacking locations. here is the scenario... currently, you get a single corp, multi locations per corp, and customers are specific to the corp. What if you could have multiple corps, multiple locations, and multiple customers - all joined together as a joiner table. - Eric was talking about a data warehouse technique of having a global id number and then cascading that id to satilite type systems. - Concepts of finding duplicates and either mapping them and/or merging records. - for the record, we are not going to be dealing with this cross-corp stuff for the first round. - We may have some problems with existing custom loyalty points and rewards systems - how are we going to migrate and/or extract that data to get out of the custom code areana and get them into the standard flow. We may need some special tools to help with this migration process. Once again, this will have to be a later release of the sub special account tracking. We also need to deal with overlap (using the old system and the new system). - Shooting for the bell curve type result... We are shooting for the 80% mark. We will deal with the other outside needs and/or features later on. - Distributing database slices to other servers. Eric has a number of ideas about databases and what DBA (database administrators) deal with. Eric has a lot of knowledge in that area. He is a great resource. We could have one database being mirrored to other servers. All of this does come at a price and/or cost.