1 / 33

Parramatta City

Parramatta City. meals on wheels (MOW). Brian Shaughnessy Lighthouse Consulting & Design www.lcdservices.biz. background. district/region of Sydney provides services to the residents CiviCRM used extensively for back-office support meals on wheels. meals on wheels.

joshua
Download Presentation

Parramatta City

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • meals on wheels

  3. meals on wheels • serves elderly citizens of the district • delivers meals at discounted prices M-F • provides various options • chilled/frozen meals • soups • salads • juice • 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 • week/year [one order per week/year; future only] • 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

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

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

  8. 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

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

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

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

  12. 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 • tracks current levels • line item stored as activities

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

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

  15. packaging labels

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

  17. full delivery run sheet

  18. order invoices • generate invoices for pending payments or by date range

  19. order invoices

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

  21. order statement

  22. other stuff • active services • custom data group • other data groups dependent on active status

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

  24. quarterly stats report

  25. what I’d 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)

  26. 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

  27. 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

More Related