1. Parramatta City meals on wheels (MOW) Brian Shaughnessy Lighthouse Consulting & Design www.lcdservices.biz

2. background district/region of Sydney provides services to the residents CiviCRM used extensively for back-office support o meals on wheels

3. meals on wheels serves elderly citizens of the district delivers meals at discounted prices M-F provides various options o chilled/frozen meals o soups o salads o juice o dessert

4. meals on wheels creative use of CiviCRM architecture allows full integration with other services managed through the site required extensive customization, but also relies heavily on the core data structures

5. activity record clients place orders on a weekly basis order details o week/year [one order per week/year; future only] o exceptions [skipped by bulk generator] custom data set for M-F with fields for each meal type dietary details stored in custom data attached to contact record

7. payment record separated order (activity) from financial obligation (contribution) modeled after event/membership structure o link activity to contribution o orders_activity_payment (activity_id, contribution_id) added support for > 1 payment per order

8. payment record auto-created with activity order calculates total due based on standard meal rates o constants defined in code o eventually place in option values detail the order in contribution record record changes to the order o adjustment to contribution record o order history through notes (>1 per contrib)

12. bulk order generation clients place orders on a weekly basis most orders are exactly the same from one week to the next needed to develop method for quickly generating future-week activity records based on prior week

13. bulk order generation manually triggered, but options locked down log table tracks bulk order history o determine last week run o log order counts and activity IDs

15. bulk order: special handling order exceptions o skipped by bulk order generator o most immediate prior non-exception order used account for existing orders for a given week/year on-hold o hold start date/hold end date o if any overlap, skip bulk generation

16. bulk order: special handling third party payer o soft credit to client o payment to TPP entity o handled with relationship defining when TPP begins/ends admin fee o system default; contact override direct deposit o set contrib status = completed o else = pending

17. stock management set starting values update when order is created/updated/deleted special contact: Parramatta Stock Manager stock adjustment activity types dashlet report to summarize current levels summary data handled in stock_log table o tracks current levels line item stored as activities

19. reporting ughhhh… originally planned to use reporting framework o specs required many unique calculations o unique data handling (field criteria interaction) o too many options most reports built (or rebuilt) as purely custom implementations

20. packaging labels generate by week number/year calculate number of packages based on meal/salad/soup/dessert combo track frozen/chilled

21. packaging labels

22. full delivery run sheet used by delivery staff each contact is assigned a run number (geographic assignment) MS Word export (scalability/easy to modify)

23. full delivery run sheet

24. order invoices generate invoices for pending payments or by date range

25. order invoices

26. order statements filter by payment status, contact, date range calculate balance based on various criteria

27. order statement

28. other stuff active services o custom data group o other data groups dependent on active status

29. quarterly stats report generate calculations per service for a variety of stats

30. quarterly stats report

31. what Id do differently… torture by custom field proliferation… move as much as possible into dedicated CRM path spend more time working through data model with client better method for classifying meal field types spend more time developing specs. for report requirements (much time was spent, but it always seems like more is needed)

32. challenges deciding what to lock down to prevent user- created failures date-model (week/year): effective for the situation, but required some "translation" for end users end of year wrap-around a pain mission-critical system with constantly evolving specs

33. project status core system in production for approx. 1 year ongoing report/statement/invoice tweaking for quite some time currently wrapping up final adjustments for reports and closing the project