Nimble Lead to Cash

Lead to Cash by NimblePlugins is a self-hosted workflow for service businesses that want to manage the path from enquiry to invoice inside WordPress.

The Free plugin includes:

• Enquiries and manual lead creation
• Customers
• Quotes and PDF documents
• Jobs and completed work
• Invoices and payment tracking
• Standard reports and an audit log
• In-app notifications
• Search and export tools
• Local encryption of sensitive fields
• WordPress personal-data export and erasure integration
• English as the default product language
• Danish language and economic defaults
• A searchable Help & FAQ centre in English and Danish
• Lead to Cash user administration in WordPress
• Scheduled backups of Lead to Cash data, kept on the server, with restore and import of a saved backup file

Lead to Cash contains no licence check, no account requirement and no time limit. A product key applies only to the separately installed Lead to Cash Pro add-on, whose code is not part of this plugin.

Your operational data is stored in dedicated tables in your WordPress database, and backups are kept there too. It leaves the server only when you ask it to: see External services.

Product information: https://nimbleplugins.com/lead-to-cash/

External services

Lead to Cash runs on your own server and never contacts NimblePlugins. It contacts the services below, and only for the feature named.

Danish company register, CVR (only when a user looks up a CVR number)

When a user enters a Danish CVR number on a customer card and asks for the details, the eight-digit number is sent to cvrapi.dk to fetch the registered company name and address. The request also carries this site’s host name in the User-Agent header, because cvrapi.dk rejects anonymous calls. Nothing else is sent, and no customer data leaves the site. An answer is cached for twelve hours, so looking the same number up again does not call out again.

Service: https://cvrapi.dk/ – Terms: https://cvrapi.dk/terms – What data they hold and why: https://cvrapi.dk/help

VAT-number lookup (only when a user clicks it)

When a user looks up a customer’s VAT number, the country code and the number are sent to the European Commission’s VIES service (ec.europa.eu) to fetch the registered company name and address. Nothing else is sent. Service: https://ec.europa.eu/taxation_customs/vies/ – Legal notice: https://commission.europa.eu/legal-notice_en – Privacy: https://commission.europa.eu/privacy-policy-websites-managed-european-commission_en

Logo and payment QR image

If the company logo or payment QR code is given as a web address, Lead to Cash downloads that image to place it in PDF documents. Only the address you enter is requested, and nothing about your data is sent. Normally this is an image in your own media library.

Backup destinations (only with the separate Pro add-on)

Lead to Cash takes backups and keeps them on this server. Sending a copy somewhere else is what Pro adds: Pro registers the destinations, and without Pro there are none, so a backup stays where it was made.

This package does contain the Dropbox client class, because Pro builds on it rather than carrying its own copy. It is never reached without Pro: every path to it runs through a destination, and no destination exists until Pro registers one.

With Pro installed and a destination configured, the backup archive is uploaded to the destination you chose, each time a backup runs. The archive contains all Lead to Cash data, so choose a destination you would trust with the database itself.

Dropbox: https://www.dropbox.com/ – Terms: https://www.dropbox.com/terms – Privacy: https://www.dropbox.com/privacy

Google Drive: https://www.google.com/drive/ – Terms: https://policies.google.com/terms – Privacy: https://policies.google.com/privacy

OneDrive and SharePoint: https://www.microsoft.com/microsoft-365/onedrive – Terms: https://www.microsoft.com/servicesagreement – Privacy: https://www.microsoft.com/en-us/privacy/privacystatement

SFTP and webhook destinations go to an address you enter yourself; no third party is involved beyond the one you choose.

Source code

Lead to Cash has no build step. The JavaScript and CSS shipped in frontend/ and admin/ are the source: written by hand, not generated, bundled or minified, and they are the same files the browser loads. There is nothing to un-minify, and there are no build tools to document.

Privacy

Lead to Cash stores contact details, enquiry details, notes, document data and activity history in the local WordPress database. Sensitive fields are encrypted locally.

The plugin integrates with WordPress personal-data export and erasure tools. Site administrators remain responsible for defining suitable retention periods. Financial records may need to be retained under applicable bookkeeping rules.

Lead to Cash does not contact NimblePlugins. Backups sent to a destination contain all Lead to Cash data; choose a destination you would trust with the database itself.

readme.txt carries only the most recent entries, because the plugin
directory truncates that section at 5000 characters. Everything is here.

1.37.29

• Tabellen til udgaaende beskeder bliver nu faktisk oprettet naar en
  eksisterende installation opdaterer. Tabellen kom med i 1.37.28, men
  skemaversionen blev staaende paa 0.9.2, og opgraderingen koerer kun
  skematrinnet naar den vaerdi aendrer sig. En ny installation fik tabellen,
  en opdateret gjorde ikke – og fejlen kunne kun ses paa et site der havde
  pluginnet i forvejen.

1.37.28

• Henvendelser tælles nu på hvornår de kom ind, ikke på hvornår de blev
  skrevet ned. En henvendelse fra juli, der først tastes ind i oktober,
  hørte til oktober i rapporten – så juli mistede den, og oktober fik en
  for meget. Feltet “Modtaget” på henvendelsen afgør det, og rapporten,
  ugetællingen og begge lister regner nu på det samme.

1.37.25

• Gennemført én regel i rapporten: det realiserede vinder altid. Er der
  først en faktura på en opgave eller en henvendelse, ER fakturaen værdien,
  og budgettet eller det aftalte beløb tæller ikke med nogen steder – hverken
  som rest eller som et højere tal.
• Restbeløbet på delvist fakturerede opgaver er fjernet helt.
• “Gns. hvor værdien er kendt” tog før det største af det fakturerede og det
  aftalte. Et budget, ingen nogensinde fakturerede, kunne dermed slå den
  faktura, der afsluttede sagen. Nu er det fakturaen, når der er en.
• “Aftalt, endnu ikke faktureret” dækker nu kun sager helt uden faktura.

1.37.24

• Noterne under Samlet opgaveværdi er fjernet. Opdelingen står allerede på
  siden, og tre linjer under et tal gør kortet sværere at læse, ikke lettere.

1.37.23

• Henvendelsesraten talte forud. Med en periode, der løb til 31. december,
  blev november og december regnet med som stille måneder, og raten blev
  delt med tid, der ikke var gået: 48 henvendelser blev til 9,1 om måneden
  i stedet for 18,7. Den regner nu frem til i dag, som ugelisten altid har
  gjort.

1.37.22

• Rapporter målte værdi på henvendelser. En henvendelse er ikke en værdi, og
  en kunde er det heller ikke – værdien opstår først, når nogen skriver ned,
  hvad en opgave koster. Kortet hedder nu “Samlet opgaveværdi” og er det
  fakturerede plus budgettet på de opgaver, der endnu ikke er faktureret.
• Er en opgave budgetteret højere, end den er faktureret, står forskellen
  frem som aftalt, ikke endnu faktureret arbejde. Før forsvandt den helt.
• Rapportperioden starter som hele indeværende år, 1. januar til 31. december,
  i stedet for et vindue, der gled en dag frem hver morgen.

1.37.21

• Statusfilteret “Alle” på opgavelisten skjulte de afsluttede. Det modsagde sit
  eget navn, og en afsluttet opgave kunne kun ses i den separate
  Afsluttede-visning. “Alle” betyder nu alle.
• “Planlagt” er valgt som standard, for det er den liste, man handler på.

1.37.20

• Opgaver kunne blive til tvillinger. Gemmestien afgjorde opret-eller-opdatér
  ud fra et data-attribut på formularen, som blev nulstillet, hver gang
  dialogen blev lukket. En formular, der havde mistet sit id, oprettede derfor
  en ny opgave i stedet for at gemme den, der stod på skærmen. Identiteten
  læses nu af selve posten; attributtet er kun et krydstjek.
• Opretter du en opgave på en kunde, der allerede har en åben, viser appen de
  eksisterende og spørger, før den opretter. Serveren afviser en ubekræftet
  dublet og sender de åbne opgaver med tilbage, så spørgsmålet kan nævne dem.
  Det er et spørgsmål, ikke et forbud — to åbne opgaver på samme kunde er ofte
  rigtigt.
• Nøgletallet på opgavelisten var ét tal, der lagde fakturerede beløb sammen
  med håndtastede budgetter, og som talte alle opgaver med — også de
  afsluttede, tabellen ikke viser. Samme arbejde kunne derfor tælle to gange:
  én gang som omsætning på den afsluttede opgave, én gang som forventning på
  tvillingen. Det er nu to tal — Faktureret og Forventet — og begge følger det,
  der står i listen, så filter og søgning virker på dem.
• Økonomikolonnen blandede momsgrundlag: fakturerede opgaver viste beløb
  inklusive moms, resten viste budget uden. Alt vises nu ekskl. moms, og det
  står i kolonneoverskriften.

1.37.19

• Appens adresse kan nu vælges. Har sitet allerede en side på /lead-to-cash/ —
  en produktside, en landingsside — nægtede pluginnet at blive aktiveret, og
  eneste udvej var at omdøbe den eksisterende side. Det er ikke rimeligt at
  forlange af et site, der havde adressen først. Sæt
  define( ‘NIMBLE_LTC_APP_SLUG’, ‘din-slug’ ); i wp-config.php før
  aktivering, så bruger appen den i stedet. Pro henter PWA’ens id, start_url,
  scope og Service-Worker-Allowed fra samme konstant, så det følger med.
• Fejlbeskeden ved adressekonflikt sagde ikke, hvad man skulle gøre, og skrev
  altid “/lead-to-cash/” selv hvis appen lå et andet sted. Den viser nu den
  rigtige adresse og nævner konstanten.
• Bemærk: ændrer man adressen på en eksisterende installation, skal
  permalinks gemmes igen, og PWA’en skifter scope, så genveje må tilføjes
  forfra.

1.37.18

• Kundekortets overskrift stacker nu ordentligt på telefon. Henvisningen “Også
  kunde som …” klemte sig ind ved siden af navnet, wrappede over tre linjer og
  maste lukkekrydset. Navn og kryds beholder den første række, og henvisningen
  får en række for sig selv nedenunder. Et langt kundenavn kan ikke længere
  vokse chippen — den afkortes med ellipse.

1.37.17

• Henvisningen “Også kunde som …” flugter nu med kundens navn i kortets
  overskrift, og den er endelig guld. Farverne gik før gennem en kæde af
  CSS-variabler inde i color-mix(); brister et led i den kæde, bliver
  variablen ugyldig, teksten arver hvid og baggrunden falder tilbage til den
  almindelige knapstil — præcis den blå, den ikke måtte være. Farverne står nu
  direkte, med en mørk guld til lyst tema og en lys til mørkt.

1.37.16

• Henvisningen “Også kunde som …” er flyttet helt op i kortets egen overskrift,
  ved siden af kundens navn, og er nu guld. Guld bruges ikke andre steder i
  produktet, så den kan hverken forveksles med de blå handlingsknapper eller
  med noget andet. På smalle skærme falder den ned på sin egen linje.

1.37.15

• Henvisningen “Også kunde som …” er flyttet op i toppen af kundekortet, lige
  under “Kontakt oprettet …”, og har fået sin egen farve. Den lignede før en
  primær handlingsknap ved siden af “Opret tilbud” — temaet giver en bar
  den primære knapstil, og .link-button fandtes ikke i Free. Den er nu
  en chip i accentfarven, så den ikke forveksles med kortets handlinger.

1.37.14

• Retter en fejl i 1.37.13, der gjorde alle kundekort ubrugelige med “Cannot
  set properties of null (setting ‘hidden’)”. Henvisningslinjen “Også kunde
  som …” blev sat ind i skabelonen med forkert elementtype, så et </div> kom
  til at lukke et <section>. Resten af kortet endte dermed uden for DOM’en,
  og opslaget på det første element derefter gav null.

1.37.13

• Privat og erhverv holdes nu adskilt på kundekortet. De samme mennesker er
  ofte kunde to gange med vilje — privat og gennem deres selskab — og det er to
  kunder med hver sine henvendelser og hvert sit regnskab. Henvendelser,
  handlinger og aktivitetslog blev slået sammen på tværs af kontakter med samme
  mail eller telefonnummer, så det private kort viste selskabets henvendelser og
  omvendt. Det gør de ikke længere.
• I stedet står der øverst på kortet “Også kunde som …” med et klik over til
  den anden. Det er den ene linje, hvor de to kender hinanden.
• 1.37.12 slog fakturaerne sammen samme vej. Det er rullet tilbage: et kort
  viser sine egne fakturaer og sit eget udestående, så selskabets gæld ikke
  lander på privatpersonen.

1.37.12

• Kundekortet viser nu fakturaerne for alle kontakter, der hører til samme
  person. En kunde kan ligge på mere end én kontaktrække — en privat og det
  selskab, der faktureres igennem, koblet på samme mail eller telefon — og
  henvendelserne og aktivitetsloggen har hele tiden vist dem alle. Kun
  fakturalisten gjorde det ikke, så kortet modsagde sig selv: loggen fortalte
  at en faktura var sendt, mens listen nedenunder sagde ingen fakturaer.
• Værdikolonnen på henvendelserne viser det fakturerede beløb, når der er
  faktureret på opgaven, og ellers estimatet. Kladder tæller ikke med — der er
  intet faktureret, før dokumentet er udstedt — og kreditnotaer trækkes fra, så
  en krediteret opgave ikke står med penge, der er givet tilbage.

1.37.11

• A credit note can be issued again. It has no due date – it is immediate, and the VAT rules ask a credit note for the same ten things they ask an invoice for, a due date among none of them – so the one the plugin creates correctly leaves that field empty. Finalising it then refused the note as its own work: “The due date is invalid.” Three more places would have refused it next, and the dialog’s date field was marked required, so the browser stopped the save before any of it. All four now make the exception for a credit note, and only for a credit note: an invoice without a due date is still refused.
• The contact person can be set on an invoice. It is the “Att.” line the document prints, and until now it was whatever stood on the customer when the invoice was made, with no way to change it. The invoice keeps its own copy of the customer, so a different att. here changes this one document and leaves the customer record, and every other invoice, alone – which is what is wanted when the work was agreed with one person and the invoice goes to another. Shown for business customers, because a contact person is not stored on a private one.

1.37.10

• Luft mellem vilkårene og underskriften i tilbudsbrevet. Afstanden var mindre
  end mellem to linjer i afsnittet selv, så “Med venlig hilsen” lagde sig op ad
  den sidste betingelse og lignede en linje mere i vilkårene.

The full history from 1.0.0 onwards is in changelog.txt, which ships with
the plugin.

1.37.9

• The payment QR code reaches the invoice the customer receives. A payment add-on fills the QR slot, and to build a code for one particular invoice it has to know which invoice it is – but the filter was called without it, leaving the add-on to work it out from the web address. That only matched the preview and download links, so the code appeared where the business looks …