Parramatta City meals on wheels (MOW) Brian Shaughnessy Lighthouse Consulting & Design .

Parramatta Citymeals on wheels (MOW)

Brian ShaughnessyLighthouse Consulting & Design

www.lcdservices.biz

background district/region of Sydney provides services to the residents CiviCRM used extensively for back-office

supporto meals on wheels

meals on wheels serves elderly citizens of the district delivers meals at discounted prices M-F provides various options

o chilled/frozen mealso soupso saladso juiceo dessert

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

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

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

payment record auto-created with activity order calculates total due based on standard meal

rateso constants defined in codeo eventually place in option values

detail the order in contribution record record changes to the order

o adjustment to contribution recordo order history through notes (>1 per contrib)

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

bulk order generation manually triggered, but options locked down log table tracks bulk order history

o determine last week runo log order counts and activity IDs

bulk order: special handling order exceptions

o skipped by bulk order generatoro most immediate prior non-exception order used

account for existing orders for a given week/year

on-holdo hold start date/hold end dateo if any overlap, skip bulk generation

bulk order: special handling third party payer

o soft credit to cliento payment to TPP entityo handled with relationship defining when TPP

begins/ends

admin feeo system default; contact override

direct deposito set contrib status = completedo else = pending

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

reporting ughhhh… originally planned to use

reporting frameworko specs required many unique

calculationso unique data handling

(field criteria interaction)o too many options

most reports built (or rebuilt) as purely custom implementations

packaging labels generate by week number/year calculate number of packages based on

meal/salad/soup/dessert combo track frozen/chilled

packaging labels

full delivery run sheet used by delivery staff each contact is assigned a run number

(geographic assignment) MS Word export (scalability/easy to modify)

full delivery run sheet

order invoices generate invoices for pending payments or by

date range

order invoices

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

order statement

other stuff active services

o custom data groupo other data groups dependent on active status

quarterly stats report generate calculations per service for a variety

of stats

quarterly stats report

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)

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

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