Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Yellow
Assigned To: Brandon Moore
Created By: Brandon Moore
Created Date/Time: 3/29/2023 2:44 pm
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 9996
Template/Type: Brandon Time
Title/Caption: Working on known issues list
Start Date/Time: 3/29/2023 10:45 am
End Date/Time: 3/29/2023 12:45 pm
Main Status: Active

Sorry, no photos available for this element of time.


Notes:

Recording notes and working on a list of known issues. See top_secret/secure/known_issues.cfm for more information.

For fun, here is a list of some of the items listed on that page. This list originally was started in 2009. Small list of what are known problems. Some of these things are real problems and some are just warnings. Lots of things have changed since then. It may need to be updated, added to, and some of the items removed, that have been patched, fixed, and/or finished.


  1. Invoice pmts on account with something different than 0.00 value.

  2. Receipt pmts on account with something different than 0.00 value.

  3. Reimbursements (rei's) with a bank assigned on the receipt pmt.

  4. Invoices with mismatch between main and line items.

  5. Deposits with mismatch between main and line items.

  6. Receipts with mismatch between main and line items.

  7. PO's with mismatch between main and line items.

  8. Non verified payments (outstanding deposits and checks).

  9. Duplicates ???

  10. Dates prior to the corp start date or prior to the bank start date. See bank_balance_helper.cfm page.

  11. Dates in the future. see bank_balance_helper.cfm page.

  12. Internal invoices that are not marked as paid.

  13. Receipt payments that are verified but the main is not verified.

  14. Difference between invoices and stock numbers. Created a number of flags to show disconnect.

  15. When paying back splits and rei's - what about both (main and subs) being assigned to income statement expense types? This could double things up on the income statement. Defaulted special multi build (rei and splits) to b.s. items for expense types. Still possible problem on original e/r that may get assigned to the balance sheet.

  16. Update PO's not tied to a balance sheet item (say a loss account or something).

  17. Lien payoff line items on invoice with a 0 cost. The cost and the price should be the same otherwise it puffs up the profit. Did run a report at one time to fix this. Also added code to the cart to match cost and price for lien payoff stuff.

  18. PO payments that have the wrong date and thus the po_paid date is wrong. The system was using the current date as the payment date even if the payment was actually made in the past. Small disconnect between actual payment date (e/r payment date and PO paid date).

  19. Check auto dates that are actually used in I.S. reports or B.S. reports. Need a way to manually change the auto dates if really being used. Check the unit payments, PO payments, other system made payments. The system seems to be ok, the problem is with dates and being able to either set the date when using or edit the date if defaulted to today's date.

  20. Blank expense/receipts (payee_id = 1).

  21. Voided items but part of it is still in play or not fully voided. Need to get to a voided list quickly.

  22. Denied check requests on payables page.

  23. Sales tax problem with work in progress invoices. They don't show up on sales tax reports until they get flipped back to a customer invoice. The problem is that the date (main invoice date - if not moved forward) will not show up on the next month’s tax reports. If this happens, the invoice will fall through the cracks and not be counted for sales tax. Possible option for sales tax, Steve thought that it might be cool to have a point and click interface that we physically pay taxes on certain invoices. That way, they never fall through the cracks and we only pay taxes once we collect the monies. This would also help with a system-maintained b.s. item for accrued sales tax. As an update, Eric was working on a sales tax aggregate project to automate this.

  24. Along with sales tax problems, how do we show this on the balance sheet? We need to show collected, paid, and owed values. Once again, Eric has been working on this in his sales tax aggerate project.

  25. Payroll has similar problems with regards to what has been paid on, what is still needed, and how do we show this info on the financials.

  26. See idea in note book about showing all daily transactions. This is different than a history transaction record. This is what really hit in and out on this day in time according to the system. This is not a known issue but may help with finding issues. Daily monitoring of each account per location, per day, per account or category. This would be awesome.

  27. Check for master/slave relationships between date changes. For instance main invoice date compared with invoice line items dates. PO main date with PO line items date.

  28. Known issue with PO dates. Do we run off the main PO date or the PO received date? Need to standardize. Leaning towards PO received date.

  29. Known issue with location based payables. Both expense/receipts and deposits have the location on the line items not the main. This means that monies could potentially get split between stores which would alter bank balances if only part of the money went in/out of the bank. Known problem here. Solution might be that banks are what they are (full monies in/out) and all sub lines and types are location specific. This could give a false indication as to how much money was available for each location.

  30. What about transition invoices that have the main invoice date overlapping the transition (wip/qti) invoice date range. They don't show up anywhere other than on the main invoice homepage which doesn't tie to anything. Added a small fix on view_transition_dates.cfm page. Still need to check for possible mismatches.

  31. Disconnect between sold date on units and invoice date. This is a disconnect that is unmonitored and will only show up if pulling a sold report (units) and an invoice report for the same time frame.

  32. When backing up the main bank start date, there is a problem with expense payments and deposits that have a date before the main start date and a verified date after the main date. The payment or deposit date is not counted but the verified date is. I had the same problem with Leanna in Poncha and with Drew Middlemiss doing his first bank statement. What a pain. See the bank_balance_helper.cfm report (5/16/09) for small fix. Still a known problem with a starting bank balance not being 0.00.

  33. Advanced pmt on invoices (pre-paid). They hit the bank because they were deposited but they also need to show up as a liability to offset the deposit or cash going up. This should be a system maintained item.

  34. What about deposit types of other income that are assigned to invoices (double counted)? The default is an invoice hits the p&l and only deposit line items that are under other income and revenue adjustments hit or the p&l.

  35. What about bad debt? Do we want to create a system maintained items for this?

  36. What about deposits that are made before pmts are posted to invoices. This is not backward compatible.

  37. Know disconnect between PO dates. The main PO date is currently used as the main search date. The PO received date is the main b.s. date. We are thinking that the main date may become somewhat of a request date or a age player only. The main date will become the received date with the received flag.

  38. If a check request gets approved and assigned to a bank but never written out (bank never sees it), there seems to be a problem. There is also a problem with older check requests and the dates that are set in the background. They are uneditable once the request changes into a normal e/r.

  39. Known issue with i.s. (income statement) deposit types. If used, without an invoice, they don't show up on the income statement. They may also be double booked if on an invoice and also recorded as other income or revenue adjustment.

  40. What about payments made on a PO before it was received. This could happen with a request PO or a basic PO that has not yet been received.

  41. What about inactive (status) on parts and subs. If we have details (activity) but something is inactive, that could cause problems.

  42. Levels of inventory - this could deal with parents, subs, and usage details. We may need to check costs, quantities, dates, etc. Sub inventory was added way after 2009 (original date of this report). We may want to spend a whole session just going over sub inventory levels and possible pit falls.

  43. Steve, Kelly, Molly, and others have lists of balance sheet challenges and other known issues. Check with them and get their lists.

  44. Ecommerce and what plays into the real mix from there - invoices, taxes, costs, prices, discounts, payments, quantities, elements of time, etc. Good questions? Some of this is already figured out, it just needs a little bit of loving.

  45. What about aggregates (somewhat new for us and just barely getting rolled out) and making sure things match up. Category (could be whatever), by day, by location - are there update processes that may be ran to keep things up to date. Manual updates, API sockets, watchers and feeders.

  46. What about backorders? Steve did a whole section on backorders but I'm not sure if we tied in everything to the balance sheet and P&L. Anyways, may need to circle back around.

  47. What about banks that get turned on/off (active/inactive). If we go back in time, we need to know if they were playing.

  48. Same is turn with location. If they get turned on/off (active/inactive), we need to know when they were playing. We may need a start and end date and then be able to pull things accordingly, even if the current state or status is inactive.

  49. What about cost of goods sold on unlimited or special line items? They should be a $0.00 cost because they are unlimited (like a labor or a service). If a cost is needed, it needs to be allocated through an expense to the COGS section or distributed in a thing called SG&A costs. SG&A (selling, general and administrative expenses - aka accounting for general costs by attributing them to a single unit and thus incorporating the true costs into an item). Basically, you take a normal expense like the electric bill or rent and build it into the individual cost of each unit by unitizing the expenses and virtually spreading a bigger general cost to smaller pieces. Sometimes that type of process (SG&A) is required for certain manufacturing and/or production type products. Basically, they (the IRS) don't allow you to expense off the whole expense (rent, insurance, waste, electric, etc.) as a bulk item. It has to be distributed to each smaller piece. If you do real SG&A, it helps assimilate those costs in smaller percentages and thus passing on a truer look at real costs of goods sold.

  50. Anything that is currently marked inactive but may have played a role at some point. This could be locations, banks, part categories, items, vendors, customers, etc. Often, if we make them inactive, they don't get pulled (but maybe we need them at some time in the past).

  51. Other special account options such as in-store credits, vendor credits, punch cards, etc. We already have loyalty points and gift cards that use special accounts. Maybe expand on this and allow for custom options or other digital payment accounts or payment solutions.

  52. I'd love to map out all of the existing balance sheet and P&L values. Make it more widely known and really put it out there. Right now, it all happens behind the scenes and is kinda like a magic box. I'd love to get it all mapped out and presented to the public. We'll get feedback, refinement, and maybe even some other really good ideas. That's my vote, let's get it all out there in the public eye and public realm.


Additional Comments/Notes - Subs (2)
Title/Caption Date Time Done By Comment/Note
PO lines and sub inventory lines 5/15/2023 4:53 pm Brandon Moore

Kelly pointed out that if there is a disconnect between the main PO line items (at the parent level) and the sub inventory lines, there can be quantity and cost (retail value) errors. She showed us an example. The main PO wasn't showing an error or disconnect, but the parent and sub lines were not matching. It was throwing an error later on in the reporting and balance sheet. We need to be able to monitor that relationship between the line items and the sub inventory lines.

Invoice payments for loyalty points and gift cards with auto deposits 5/10/2023 5:39 pm Brandon Moore

We ran into a problem between auto deposited invoice payments and the deposited date. This is especially true if the user is back dating the invoice. There is a difference between the transaction date (real invoice payment date) and the adjusted date/time stamp (now or server time adjusted to the time zone). If both are done at the same time, no problem. However, if the transaction or invoice date is different, the use of the adjusted date/time can create a disconnect. The guys were doing a demo and back dating tons of invoices with loyalty points and gift card payments. We ran into a few issues. Some of the money type id's that have auto deposits (as of 5/10/23) are "11,17,36,39" or "11=Internal, 17=bad debt, 36=Rewards/Loyalty, and 39 = spingbig Points". To fix it, they had to find the invoice, go the edit line items and payments and change the deposit status date (link that says status) by the invoice payment. Ideally, we want to control this date when first adding the invoice payment, make sure it matches the real date (allow for back dating). We also want to be careful if the users flips the date after the fact. We flip most of the dates, but the deposited_date may not be being flipped. All of this auto depositing of invoice payments needs to track the other pieces all the way through.