Skip to main content

Planning

The core of v14. Planning happens in svr-api under the v2/preneed folder and the data is saved on the user model under user.preneed. Documentation can be found here: https://docs.google.com/document/d/1xrGibq7Ct0I_KgWbp6xcbmqTy6SCYx0id0I73n5URiU/edit?usp=sharing

Packages (via KB)​

Our packages structure is a bit complex. Packages are their own thing, but they also have to be a part of each funeral home. We wanted a way to be able to see/edit packages, without having to update all the homes (unless a package is changed like adding a new service or changing a default price).

Data model: preneed-package.model.js, preneed-package-service.model.js

Data file in our repo: svr-api/v2/data/packagesAndServices.json

Data file that is actually loaded: https://everdays-resources.s3.amazonaws.com/preneed/packagesAndServices.json

A package has a bunch of properties: packageId, default price, order for display, and so many copy strings for display in various places. There are plenty in the json file that arent used too at this point.

A package also has services. In the json and package model you can see package.services. This is not an array but an object. Just like there are 3 packages. We initially designed everything to have an id in the name like package1 or service15 for example in order to then build a mapped price structure on each home. (see funeral-home.model.js for preneedPackages { ... })

Each service is also listed in the json file - those are thankfully fairly straightforward; one of the more important service elements to notice is addOn: true. Each package has services and it has addOns .. to the business and consumer a service is different from an addOn (or now its called ‘upgrade’ in biz terms I think.

Since things are already up and running, it will help to look at a few things. In the database look at the preneedpackages and preneedpackagesservices collections. Packages as of v14 aren’t an exact thing for a consumer any more - they dont really know they’re buying a specific package, but the funeral homes are still setting up pricing for packages so go look at a Schoedinger home in the web dashboard, and also in the database (query the funeralhomes collection with {packageSetupComplete: true} ) and you will see something like:

3 things that happen via the business:

  1. Quiet often copy changes and on a package - like a subtitle, the change needs to be made in the json file, then push the json file to s3, and then use postman to hit our package dataloader endpoint: POST https://everdays.com/v2/private/oneOffs/dataload/packages
  2. If services are added or removed then there is an endpoint you’ll have to hook up - its not available to just use. Set up something in the public.route.js to route to oneOffsController.js PUT /updateHomesPackageData You can then hit this endpoint and it will update the services on all homes that have packages.
  3. If a service has its price change .. the business might say change Basic Services from 2350 to 2450 .. so first, make this change in the json file and upload it to s3 and run the dataloader. Then there’s another endpoint thats not hooked up that can be modified and routed in public.route.js to be used. In the oneOffsController.js PUT /updateAllHomesPackageDataDueToPriceChange You’ll have to change the service id in the line const serviceWithPriceChange = 'service3';

Something else to note about services. Homes wanted to be able to change the value of a service based on a package .. so package0, package1, package2 used to share basic service service1 but then we had to turn that into service1000, service1001, and service1002 .. you’ll notice addon services are like this too.

Because of the craziness and evolution of packages, when package data is returned to the consumer frontends, it is transformed via svr-api/lib/v2/preneed/etc/transformPackage.js When funeral homes with package data go back to the consumer we also transform them via v2/preneed/etc/setPackagesOnProviders.js

There’s plenty of other ins and outs I’m missing, but one other important thing is when a user submits an order to buy a package .. the v2/preneed submitOrder ep is hit. This just alerts the CS team and then they use postman to hit POST ​​/startsaleinternal (preneed.controller) which returns an eFuneral link they give to the user for them to enter payment info. When a user enters payment info, eFuneral then makes a First Callback to our endpoint /sale (preneed.controller) and then they make a Second Callback to that same endpoint when they and the funeral home have signed the contract. This saves a pdf of the contract in s3 everdays-efuneral-receipts. Each contract has the sale id that matches user.preneed.efuneral.saleId.

If the company ever wanted to add a new package it would be an interesting decision between a complete refactor to packages given how we’ve moved away from them as a consumer concept .. or just adding packageX to the json file, the model, and then the various places in svr-api as well as the director dash, and preneed apps where 3 packages are whats expected.

Adding a Package​

  • v2/data/packagesAndServices.json -need to add a packageX (copy package0,1or 2) and then mod the services to suit whats in the new pkg.
note

Due to constant changes not all package fields are still used or make sense

svr-models/lib/preneed-package.model.js - add the new package here

  • run the dataloader for packages in the one offs controller /dataloadpackages at this point you should check the database to see the new package in the preneedpackages collection

  • all funeral homes have default or instantiated package data (fhome.preneedPackages) which has a priceStructure that set prices for the pkgs and pkg services for that home, and a homePackageIds that align with the package ids within the preneedpackages collection. each home will have to be updated to contain the new package. we have an endpoint in the one offs controller /updateHomesPackageData which is currently set up to add/remove services for the 3 existing packages we have now as of v14. A copy of this endpoint could be made to add a new package and possiibly any new pkg services to each funeral home.

  • obv this will either break the director dash to view/edit package prices, or it wont, but will need updating to allow for the new package to display/be updated.

  • update logic that sets the packageId when planning experience data is set in the preneed controller /planning post ep.

  • any pdp landing pages, pdfs

  • sending data to salesforce v2/preneed/etc/updateSalesForceLead.js new packages will need to be added to the mergeFieldsForEstimates and mergeFieldsForRealPrices variables. make sure BK does this on the salesforce side too.

  • send data to mailchimp v2/etc/mailchimp/prepMailchimpDataRequest.js there are merge fields in mailchimp used per package. add a new package to the variable mergeFieldsForEstimates using the values Nick will give you (becase he owns mailchimp)

  • there is a script/function that isnt used atm, but was at one point to help calculate package price totals .. v2/oneoffs/etc/processPackageServices.js this should be removed or updated with the new package if needs to be used again