////////////////////////////////////////// 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. /////////////////////////////////////////////////// new notes on 11/28/18 - we found a possible missing foreign key field on the corp_special_account_transactions table. It seems to be missing the link back to the corp_special_account_assignments table. The key field should be "corp_special_account_assignment_id". - On the corp assignments, we were talking about do we need an assignment for rewards and loayalty points? Or do we just need 1 generic assignment per corp for those things that everybody gets? Just some questions. Leaning towards a single generic assignment for things like rewards and loyalty points. It is a given, that there will be multi assignments for things like in-store credit and/or gift cards. The debate was do we need it, or should we just skip it for rewards and loyalty points. If we did a single generic assignment, it could be kinda like a giant bucket and all of the loyalty points are in one bucket. What we don't want to do is create new assignments for every customer in the database per corp... that would blow up that table (number of individual records). - We keep finding small little things... we may want to run some more scenarios to really flush things out. Not huge things, but we have found some little things that are slightly off. It would be better to add things at the beginning vs adding them after the fact and then having to go back through everything and make sure that everything still works. - retroactivly - we don't really want to add auto account for all existing customers. However, saying that, we may need a process that allows us to set a start date and then the system loops through things and brings up assignments to a standard level. We may need some kind of tool that does do retroactive actions. - We could also build out some bulk loader tools to help the users get things up and going. This could be phase 3, 4, etc. ////////////////////////////////////////////////////// new notes on 1/8/19 - on invoice edits... Eric would like to leave the auto calculated item alone (no edits on them). You are able to make manual entries to update the auto generated pieces. If an invoice is edited, you should be able to get back to that original amount and/or calc. - We were talking about starting with the manual add/edit process. This may require a homepage for sub special account tracking. From there, they may have to choose an account type and then some sort of a drill-down to get into the right account and/or associate a new record (transaction) to the correct account. As a side note, not all accounts requre a real customer and/or vendor/payee. They could be open, general, etc. - we are going to be using permission id 59 (basic invoices) for the view only portion. We are going to be using permission id 86 (add/edit balance sheet - admin) for making manual entries. ////////////////////////////////////////////////////////////// 3/6/19 - last cross check options - still need to be added - known issue - this would be on review cart and submit cart. - open question - what rules should be default /////////////////////////////////////////////////////////// working through code review... - all of the pages need help files. do before pushing live. remove to do list notes at tops of pages, when done with help files. - the cfc for special_accounts.cfc has some methods commented out at the bottom of the page. check on those and decide what to do there. see the "updateCorpSpecialAccountTransaction" method, "getCorpSpecialAccountHistory" method, and the "addCorpSpecialAccountRuleHistory" method. - look for other notes and documentation, not sure if there is more than just this file. - there is a small image of what pages need to be reviewed and in what order... see the my docs/adilas_invoices/snipping_tool_drawings/code_review_for_eric_sub_special_accounts.jpg image. - standardize the navigation. some pages have links, some buttons, some icon menus. make sure we get things tight. on 5/6/19... working on the corp tranactions homepage and the add/edit transactions and searching and showing the transactions (section 5 and 6 on the image) ///////////////////////////////////////////////////////// back on the project 7/22/19 - make sure and update the file name and links for the database update... it was update_20180828.cfm, then update_20190221.cfm - there is a clean-up link on the update page that needs to be hidden before going live. - as a side note, they they user, has to provide a password to do the clean-up, maybe it is ok to leave as is. ///////////////////////////////////////////////////////// back on the project 8/14/19 - still need to deal with the assignments. loyalty points don't have this, but some of the other special accounts will. as a side note, there is a temp field on the add/edit manual transaction page that needs to be cleaned up. maybe think about providing a look-up link to a new page where the special account id is passed in and they can filter things down. /////////////////////////////////////////////////////////// working on the project 8/26/19 - what about showing loyalty points and rewards on the invoices - multi different views - maybe turn into a toggle on/off feature - before we release this section, it my be nice to add in gift cards - these other special accounts will need the assignments part of things - we need to check for black box top_secret/secure/black_box/add_cart_payment_body_[53].cfm in the black box folder. there is some new javascript that talks to hidden required fields that may not be present in the older code. - what about invoice payments after the fact and using loyalty points to help pay for that? we may need to look into this. - what about the submit_wholesale_cart.cfm page? - what about the customer_log.cfm page? showing results. - on the view_cart.cfm page, we show summaries but don't really show the $ value of points that have been earned. - on the submit cart page, i added a lot of error handling... is it too much? is in in the right spot? mostly catches for method calls. /////////////////////////////////////////////////////////////////// talking with eric and steve about loyalty points 8/29/19 - the value of the loyalty points - at the time of earning or at the time of redemtion? those values may be different - what about showing them (special accounts) on invoices or after the fact - what about going back in time and trying to figure out dollar/point ratios and values... going backwards gets a little bit tricky - histories and drill-downs to activity on these special accounts. maybe being able to search (quick search) on special accounts. how do we get to the underlying details. - we are seeing more and more possible settings and configurations for each section and/or type. - ecommerce may end up being another avenue for some of these special account types (say gift cards, earning loyalty points, etc.) - we are seeing lots of other needs for these payment type solutions and tracking these sub account totals, histories, and/or transactions. we are also seeing a mix between both internal (adilas) solutions and external (3rd party payment solutions) accounts of different types. - we are seeing so many different point of sale systems (different POS's and POS competition), we are hoping that some of these outside companies will decide to intregrate with us and then help push our product forward. Play the piggy back type scenario. - one-off's vs core functions and features - light talks about barriers to entry and barriers to exiting. the deeper they get, the more they have virtually bought into the meat of the product and it makes it harder to leave (barriers to exit). - clients are wanting a single solution that does what they need and is highly configurable. We are trying to be that type of solution. - beta testing and allowing certain users and clients to jump in on things before a bigger release - possible problem with bulk loyalty points old custom points vs new automated points. we may need a small bulk migration tool or something like that... this may also be a special custom page that looks at existing logic and then adds new transactions to get the starting balances in place. - maybe look at the rules for the show/hide on the invoice option - the rules have a start date... make sure and help that play into the mix. it was added in as a rule, but needs to coded through. - Steve really wanted to see how things were tied into the balance sheet - looking forward into gift cards and realy liabilities and such. That is not yet built out but needs to be a part of it. - what about a running total on the transaction home page? it might be nice. maybe show a link to show full details without any filtering (keep it hidden) and then show the running totals. just an idea. - as i started getting into more of the rules, what about active/inactive rules. currently, if i find it, it plays through. it doesn't look for active or inactive. what is the plan there? - the date might be nice to keep it going (from the transaction home) if you do a manual transaction or an edit. Otherwise, the value you just changed may not show up. we may need to pass the search criteria from the transaction home into the edit transaction page. - what about showing user histories as part of the history homepage (who is making manual changes and help that show up better). We need both kinds of histories... what shows up (effectual) and who did it (historical). - when we launch this, we may want to have ecommerce invoices be able to at least add points, even if they can't redeem those points yet. That (redemption of points) may be a later project. ///////////////////////////////////////////////////////////////////// meeting with Molly on 10/23/19 - showing the loyalty points as var or TBD - if both redeeming and adding points on a single cart... we propose that the new points being added will be: sub total invoice dollar amount - the value of the points redeemed. Normal math to calculate that new dollar amount times the ratio. - also, we want to make sure we exclude any taxes - on this page - corp_special_account_transactions_home.cfm - for loyalty points, we need to change some of the math on the total dollar value at the top and also on the dollar value in the main report. //////////////////////////////////////////////////////////////////// more notes with Erci on 11/4/19 - more possible rules... - Limit by customer type (list) - Maybe exclude by single items (list) - Maybe a date range - program start date and program end date (strings or dates) - Showing a dollar value on the receipt (toggle) - we currently already have a toggle to show the points on a customer receipt, but we haven't been showing the dollar amount, just the point amount. - Maybe look at parent attribute as a include/exclude (list) - not tons of requests on this one yet - instead of building everything, use the request base system to help us build it out. //////////////////////////////////////////////////////////////////////// ideas on 12/2/19 from Eric. Steve, Brandon, and Eric were on the call. - on customer loyalty points, we have had a few requests for double points. We are thinking that we could do that with a couple of new rules and then also have a whole other table to help record the special dates and times and how that works. think of a setting that says, do we want it yes/no. Then when they record the date/times, they would put those values (potentially unlimited) into a sub table dealing with timing. - if a user wants to bump up their points... they could log in and just up the point value. They could then change it back later on. This too, could be a future project and getting that stuff into more rules. - Steve was talking about other special accounts like single coupons, gift cards (normal), gifted gift cards, punch cards, mulitple use coupons, etc. All of these are special accounts. - brainstorming on gift cards and getting the assignments ready for this... - on the item that they want to use - setup their own item, setup as unlimited, setup as don't allow discounts - as far as values for the gift cards - maybe a preset list 5,10,15,20,25,50,100 (whatever). - maybe a 0 value and then force the person to enter it. - on selling a gift card, no rules. If they want to sell it for real monies, great. If it goes on account, that is the company's choice (not recommended - crazy double balance sheet stuff). - we need to make sure that the item doesn't get counted as revenue. talk to Steve about this one. - assign to a customer or don't - assign to a payee/vendor/user or don't - there is also a general or generic person assignment option - you could skip all known assignments - no customer id, no payee id, no general person assignment - redeem with payments - thinking money_type_id 20 - called Gift Card/Certificate - what about paying with multiple different gift cards to pay for one balance? - what about assigning that unique idenifier to the cards or gift certificate (scanning in an auto id, preset id, or userdefined value) - we need to make sure that these values are unique. - what about specific gift cards (known formats and things that work for us)? i would love to leave that open and also do some research. maybe provide some options and also let them bring what they have to the table. - rules - barcode it, scan it, type it, any method - we don't want to change the normal checkout and payment process. If needed, we may need to pop-up additional windows to help scan and validate things. - We want to make sure that we don't allow double dipping and over dipping (applying multiple payments on the same account without accounting for other transactions). - allow the transaction to hold the value of the gift card. this would be per line item. - on the assignments, we don't have to allow for direct ties to the customers or vendor/user. we could use the generic value or just skip all of those pieces. - on the first launch, maybe treat everything like a fully generic card (no customer id, no vendor/payee id, no generic name). - we need to capture the unique idenitifier at the point of sale. this is for the origianl assignment. we also need to catch the unique idenitifier when redeeming those values. - make the add process as easy as possible. trying to keep the development costs down. - the assignments has a place for keeping track of the rolling totals. that may be a good starting spot and then we could go deeper if we ever have any questions. - we talked about storage sizes... we can do up to 100 alpha/numeirc characters. we can also store up to int 10 numerics or we could dish things off to the custom_json table and store up to 65,000 characters. we also talked about storing the values as URL encoded values for database storage (that way we don't hurt our database). just some ideas on storage of the unique identifiers. - Eric is going to go out and do some research and check with some other companies that do gift cards.