Nimble Lead to Cash
| 开发者 | nimbleplugin |
|---|---|
| 更新时间 | 2026年10月22日 14:50 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
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.
https://youtu.be/JbFvNNL2Wfo
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
安装:
- Install the ZIP through Plugins > Add New > Upload Plugin, or upload the
nimble-lead-to-cashfolder to/wp-content/plugins/. - Activate Lead to Cash by NimblePlugins.
- Open Lead to Cash in the WordPress admin menu.
- Configure language and company settings.
- Open the private Lead to Cash app from the admin menu.
屏幕截图:
常见问题:
Is Pro required?
No. The workflow for enquiries, customers, quotes, jobs, invoices, reports and exports is complete on its own.
Where is customer data stored?
In dedicated tables in the site's WordPress database. Sensitive contact and activity fields are encrypted with a local installation key.
Does the Free plugin send telemetry?
No. Lead to Cash sends no analytics or telemetry.
Where is the encryption key stored?
Sensitive fields are encrypted locally with a key that is never sent anywhere. The key is read from the constant NIMBLE_LTC_ENCRYPTION_KEY_B64 in wp-config.php if you define one, and otherwise from an option in the database. Defining it in wp-config.php is recommended. It keeps the key out of the database, so a database copy on its own — a support export, a shared dump, or a vulnerability in another plugin — cannot decrypt your customer data. Lead to Cash > Overview shows the exact line to add and can remove the database copy once it is in place.
Does the plugin contact an external service?
Only when you use a feature that needs one: the VAT-number lookup, or a logo or QR image you point at by web address. Nothing is sent to NimblePlugins, and nothing is sent at all until a user asks for it. Backups stay on this server. See External services for the details.
What happens if I deactivate the plugin?
Data is preserved. Deactivation does not remove customer or pipeline data.
Can I delete all plugin data on uninstall?
Yes. This is opt-in under Lead to Cash settings. If enabled before uninstalling Free, plugin-owned database tables, settings, private storage, local backups and the encryption key are removed. Leave the option disabled to preserve records.
Can I export or erase personal data?
Yes. The plugin integrates with WordPress Tools > Export Personal Data and Erase Personal Data.
What changes when Danish is selected?
New documents use Danish defaults such as DKK, 25% VAT, CVR labels and Danish document prefixes. Existing saved documents keep their historical values.
更新日志:
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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å.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 and was missing from the PDF sent by email and from the archived copy. The invoice is now handed to the filter, and the same code appears wherever the invoice is rendered.
- Signing in lasts. The session had a flat eight-hour life from the moment of signing in and was never extended - so a working day that began at eight ended with being signed out at four, mid-task, with a two-factor code to find. It now slides: an authenticated request pushes the expiry forward, throttled to the same five-minute write that already recorded activity, and a session in regular use stays valid. Fourteen days without use ends it, and a ceiling of ninety days from the sign-in applies however much it is used, so a session cannot live indefinitely.
- A device can be remembered, so the two-factor code is not demanded on every sign-in. The choice appears beside the code field, and only when Nimble Security is installed and the site has turned remembered devices on. The password is still required on a remembered device - only the code is skipped - and the device can be removed again from Nimble Security at any time.
- The enquiry, customer and job screens are usable on a phone again. Their two columns never stacked: the activity sidebar held its 280px floor while the form column gave up everything, leaving it 114px wide on a 412px screen, with every field clipped to a few letters. The stacking rule existed, but a media query carries no specificity, so the general rule lost to the narrower one these dialogs brought with them. It is now stated at that scope. Measured at 412, 390 and 360px; the desktop layout is unchanged to the pixel.
- Settings, documents had the same fault one screen over - the side panel's second column came out ten pixels wide on a phone. Fixed in the same place.
- The frontend now reads its translations from WordPress. Its JavaScript asked for a text domain the plugin does not declare, and script translations were never registered, so every translation of the 486 frontend strings was decorative. The domain is aligned and the script registered, which means an approved translation on translate.wordpress.org now arrives without a release.
- 137 strings that the bundled dictionary did not cover appeared in English inside a translated interface. They are filled in, and the build now refuses to package a frontend where that is true again.
- A status you choose now survives an update. A one-off repair that aligned every enquiry with its newest action sat in the schema installer, which runs on every activation and every schema change - so each update quietly rolled back any status a person had set since, with nothing written to the timeline to say it had happened. It now runs once: an installation that already has a schema version is marked as done rather than repaired again, and only a fresh install, which has no enquiries to touch, reaches the query at all.
- The same repair left only Won and Lost alone, while the two live rules also protect Quote sent. A sent quote could therefore be rolled back to "Meeting" by an update. The three are now treated the same in all three places.
- An invoice notification arrives on the due date, not three days early. The query asked for everything due within three days; it now asks for what is due. Quotes keep their three days' notice - a quote expires by itself and there is something to do before it does, while an invoice needs nothing until it is actually due.
- The readme now documents every external service the plugin can reach, with what is sent, when, and links to each service's terms and privacy policy.
- Corrected the readme and a code comment that said the code for off-site backup destinations ships with the Pro add-on. The Dropbox client class ships here; Pro builds on it. Without Pro it is never reached.
- The Danish translation files are no longer bundled. Translations now come from translate.wordpress.org, which keeps them current without a release.
- The report CSV export was written in Danish throughout, even when the app was set to English, so an English user got a Danish file from an English screen. Every row label is now translated; the Danish wording is unchanged.
- Two dashboard tiles counted invoices with the Danish word "fakturaer" in the English interface. They now say "invoice" or "invoices".
- Two labels were written in Danish directly in the template, so they stayed Danish whatever language the app was set to: the "Create credit note" button on an invoice, and the default quote introduction field in settings. Both are English now, with the Danish kept in the translation dictionary, so a Danish user sees no change.
- The Easy Setup screen drew its mark as the letter N in a coloured box rather than using the plugin's own icon. It now shows the icon itself.
- The app icon was the family's blue, which belongs to Nimble Security. Lead to Cash is indigo. The icon in the browser tab, on the sign-in screen, in the sidebar and on the installed app now matches the plugin's own colour, and so does the mark on the Easy Setup screen, which had the old blue written into the stylesheet rather than taking it from the icon.
- The enquiry, customer and job screens are now laid out the same way. Activity sits in a column on the right in all three, so nothing moves when an enquiry becomes a customer, and the save bar stays at the foot of the window however long the record is.
- The same screens are considerably shorter. Fields are tighter, a postcode, city and country share one line, and a billing address that matches the work address is a single line instead of a repeated form. A customer record that needed 2,944 pixels of scrolling now needs 1,645.
- Every section is a card with its own heading, so the seams between contact details, actions, documents, invoices and activity are visible at a glance.
- Documents on an enquiry were nested inside the actions panel and looked like part of it. It is its own section now.
- Renamed TermsAttachment::prepare() to attachment(). Plugin Check treats every call named prepare() as $wpdb->prepare() and reads its first parameter, which a method without parameters does not have; the check crashed on the file rather than reporting anything about it. Behaviour is unchanged.
- Five repository files were missing the note that explains their access-scope clauses, so the report still listed them. No code changed.