Setting up ERPNext selling before the first quotation goes out
The selling module in ERPNext covers quotations, sales orders, delivery notes and sales invoices, and teams configure it before go-live, alongside the Stock and Accounts modules, because those documents post to inventory and the general ledger. A sales and finance team moving quotes, orders, deliveries and invoices into ERPNext needs the selling settings, price lists, tax templates and accounts decided before anyone creates a live transaction. Each document in the chain carries the values of the one before it, so a mistake in a customer group, price list or warehouse set up early shows up later on every delivery and invoice that follows.
ERPNext is a chain of linked documents: a Quotation can be converted into a Sales Order, a Sales Order into a Delivery Note and an invoice, and each link copies item rates, taxes, party details and accounts forward. Early settings decide how that chain behaves. Confirm which document type is the stock-moving step in your process, whether invoices can be raised before delivery, and how partial deliveries and partial billing should be handled. Changing these after transactions exist usually means cancelling and correcting documents, so write the sequence down with finance and operations before configuration starts.
ERPNext is licensed under GPL-3.0 and can be self-hosted on infrastructure you control, so the selling setup is yours to run from day one. The ERPNext pricing page states that implementation is available through certified partners, so a partner can carry the configuration and testing work while your team keeps ownership of the decisions. Ask any partner for a written scope that names the settings, roles and test transactions it will deliver, and confirm which of those your own staff must sign off.
What the ERPNext selling cycle does
The selling cycle in ERPNext moves a deal through linked documents, from quotation to sales order, delivery note and sales invoice. Pricing rules and credit limits sit alongside that chain and can stop or change a document before it is submitted.
Quotation as the starting point
A Quotation records the price and terms offered to a customer before any commitment. When it is accepted, ERPNext can create a Sales Order from it, so the rates and items carry forward. Check that the quotation's validity, customer, currency and item rates match what sales has agreed, because later documents inherit them. Confirm with your own environment how the quotation-to-order mapping behaves for your version before you train sales staff on it.
Sales order as the commitment
A Sales Order is the confirmed customer commitment that drives fulfilment and stock reservation. It is the document where partial fulfilment is planned, since deliveries and invoices can be raised against its lines over time. Decide early who may submit orders, and confirm how your version handles delivery quantities below the ordered amount. Those answers determine how often the order is revisited after submission.
Delivery note and the stock trigger
A Delivery Note records goods leaving a warehouse and reduces stock for the items on it. Whether a delivery note is required before a sales invoice can be created is a setting, not a fixed rule, so your team must decide it. If you invoice without a delivery note, stock and revenue are recorded at different moments. Confirm the setting in your version and test both paths with your item types before go-live.
Sales invoice and accounting posting
A Sales Invoice books receivables and revenue in the accounting module, and it can be raised from a Sales Order or a Delivery Note. Each invoice inherits taxes, the price list and the pricing rules applied at the time of creation. Verify that tax templates, income accounts and the customer's receivable account are correct before submission, because corrections after posting usually need a cancellation or a credit note.
Pricing rules and their evaluation
Pricing Rules can replace a standard rate, apply a discount or margin, or add a free product. They are limited by item, party, quantity, value, date, warehouse, company, currency or another condition. Rules are evaluated when an item is added or the transaction is recalculated, so a rule that changes after a quotation is drafted can alter the figures. Document rule priority and test overlapping rules with realistic baskets.
Credit limits and approval exceptions
Credit limits can be set at the Customer, Customer Group and Company levels. Once a limit is reached, ERPNext can stop users from submitting a new Sales Order or Sales Invoice unless an authorized role approves the exception. Agree with finance who holds that role, how limits are reviewed, and how the Customer, Customer Group and Company levels interact. Confirm the exact blocking behavior for your version before relying on it for credit control.
Which selling settings to decide first
This table compares the selling settings that shape quotations, sales orders and invoices, with the options for each, when they fit and the trade-off. Read each row before configuring anything, because price list structure, pricing rule scope and the delivery note setting are hard to unwind once transactions exist.
| Decision | Options | When it fits | Trade-off |
|---|---|---|---|
| Price list structure | One standard selling price list, or several per customer group, territory or currency | One list fits a single price level. Separate lists fit distinct customer tiers or currencies. | More lists give control but add maintenance. Each rate change must be checked across every list. |
| Pricing rule scope | Item, party, quantity, value, date, warehouse, company or currency conditions | Narrow conditions fit negotiated deals. Broad rules fit general promotions. | Broad rules are easy to set up but can apply to transactions no one intended. Test each condition against sample quotations. |
| Pricing rule action | Replace rate, apply discount or margin, or add a free item | Replace rate for fixed contract prices. Discount or margin for flexible deals. | Replacing the rate hides the list price from the sales team. Discounts stack with other rules and need a clear precedence. |
| Credit limit level | Customer, Customer Group or Company | Customer level fits named accounts with agreed exposure. Group level fits segments with shared terms. | Customer limits need upkeep as accounts change. Company limits are coarse and may block good customers. |
| Credit limit approval role | Authorized role that can approve an exception to a blocked order | Assign to finance or credit control, not to sales staff who benefit from the sale. | A broad approval role weakens control. A narrow one slows urgent orders. |
| Delivery note before invoice | Require delivery note, or invoice directly from the sales order | Require it when stock must move before billing. Invoice directly for service or prepaid work. | Requiring a delivery note adds a step per order. Skipping it can bill goods that were never shipped. |
| Partial fulfilment handling | Deliver and invoice in parts, or hold until the full order is ready | Partial delivery fits stocked goods on long orders. Full hold fits orders that must ship complete. | Partial billing creates more invoices to reconcile. Full hold ties up stock and delays revenue. |
How pricing rules and credit limits behave in practice
Pricing Rules in ERPNext change the price or terms of an item when conditions match. A rule can replace the standard rate, apply a discount or margin, or add a free product. Conditions can narrow the rule by item, party, quantity, value, date, warehouse, company, currency or another field, so the same item can price differently for different customers and channels. Rules are evaluated when an item is added to a transaction and again when the transaction is recalculated, which means a change to quantity or customer can change the price on a document that already exists.
- Rate replacement: a rule that sets a fixed rate overrides the Price List, so confirm which source wins for each customer group.
- Discount or margin: percentage and amount rules stack on the base rate, so check the order of application before you publish rules.
- Free product: free item rules add lines that flow into stock and invoicing, so test them against your delivery settings.
- Date and quantity limits: rules with validity dates or minimum quantities can expire or change mid-order when a document is recalculated.
- Overlap: when two rules match, ERPNext uses priority and rule order, so overlapping rules are the most common source of wrong prices.
Before go-live, build a test set of quotations for each customer group and quantity band, and compare the rates against your approved price schedule. Confirm the rule documentation for your version before you rely on priority behavior.
Credit limits in ERPNext can be set at the Customer, Customer Group and Company levels. Once the limit is reached, users cannot submit a new Sales Order or Sales Invoice for that party unless an authorized role approves the exception. The control only works if the limits are kept current, because the system compares the outstanding balance against the configured amount and does not judge creditworthiness on its own.
- Customer level: a limit on one account overrides group settings for that customer, so use it for exceptions to the group rule.
- Customer Group level: a group limit suits tiers such as retail, distributor or export, and applies to every customer in the group.
- Company level: a company-wide limit applies across the company, so review it when you run several legal entities.
- Outstanding balance: the check depends on how invoices and payments post, so confirm that payment entries clear balances on time.
- Review ownership: limits need an owner who updates them after credit reviews, otherwise the control becomes a stale number.
Ask your credit team which level owns each limit, then test a blocked order and an approved exception with a user who has the approving role and one who does not. Confirm the exact behavior for your version in the credit limit documentation.
The exception path decides who can push an order past a credit limit. ERPNext lets an authorized role approve the submission, so the access design needs the same care as any other financial control. A weak role setup turns the limit into a warning that everyone overrides.
- Authorized role: name one role for credit approval and keep it separate from the sales role that creates orders.
- Segregation: the person who raises a credit exception should not be the only approver for the same account.
- Audit trail: record approvals in your change or credit log, since the document history alone may not explain the business reason.
- Role changes: removing a user from the approving role should take effect at once, so test the revocation path.
- Multi-company access: if users work across companies, confirm the approving role only applies in the intended company.
Write the approval rule into your credit policy, then test one exception end to end with a sales user, a credit approver and an auditor reviewing the log. Ask your implementation partner to show the role settings in your environment before you sign off.
Pricing and credit checks run at different points in the document lifecycle, and that timing creates most of the surprises in production. Pricing runs when lines change, while credit checks run when a document is submitted. A quotation can therefore show one price and a sales order a different one, and a credit block can appear only at submission, after the customer has already accepted the quote.
- Item added: rules evaluate as each line enters the document, so the first price a user sees is the one they may accept.
- Recalculation: changing a customer, currency or quantity can re-run rules and change rates already entered.
- Submission: credit limits are enforced when the order or invoice is submitted, not when the quotation is saved.
- Overlap effects: overlapping pricing rules and stacked discounts can give totals that match no single approved schedule.
- Conversion: a quotation converted to a sales order can pick up the rules active on the conversion date, so date-limited offers need checking.
Build a timing test that changes quantity, customer and date after the quotation is saved, then converts it to a sales order. Compare every rate and the credit result against the expected outcome, and repeat the test for each rule that overlaps.
Rule precedence and credit behavior depend on your price lists, customer groups, currencies and approval roles, so generic examples will not prove your setup. Testing with real customer and item data, in a copy of your environment, is the only reliable way to confirm which rule wins and when a block fires.
- Precedence matrix: list every rule that can match one item and record which one applies in each condition.
- Boundary values: test quantities and values exactly at each threshold, since limit and minimum checks often use inclusive or exclusive comparisons.
- Credit scenarios: test a customer under limit, at limit and over limit, with and without an approved exception.
- Regression after change: rerun the matrix after any new rule, price list change or version upgrade.
- Documentation check: record the version under test and confirm the behavior against the pricing rule and credit limit documentation.
Keep the test results with your change records, because auditors and finance reviewers will ask how a price or block was verified. Ask your partner for the test scripts, expected results and sign-off template before the build begins.
Sequence for configuring selling to go-live
This sequence takes the selling cycle from a clean master data foundation to a tested quotation-to-invoice path and a supported go-live. Each step closes with a written output that the next step depends on, so gaps surface before real customers and orders reach the system.
Confirm chart of accounts and item master
Finance and the product owner review the chart of accounts, company settings, tax templates, and the item master, including item groups, units of measure, and whether each item is a stock item or a service. The selling module posts to income and receivable accounts, so these must be settled first. Output: a signed-off chart of accounts and item list that finance and sales both approve. Ask the implementation partner to show which accounts each item group and tax template posts to before anything is priced.
Define price lists and currencies
Sales leadership and finance agree on the standard price lists, the currencies they apply to, and which customer groups or territories receive each list. The configuration assigns default price lists to customers and groups so quotations pick up the correct base rate. Output: a price list matrix showing each list, currency, customer group, and effective date, signed off by the sales owner. Confirm who maintains rates after go-live so the matrix does not drift from the commercial agreement.
Build pricing rules for discounts and promotions
Each discount, margin, free-item offer, or contract-specific rate is written as a Pricing Rule with explicit conditions on item, party, quantity, value, date, warehouse, company, or currency. Pricing rules are evaluated when an item is added or the transaction is recalculated, so the team tests overlapping rules and their priority order. Output: a rule register with one test quotation per rule showing the expected rate, reviewed by sales and finance. Include a review step for rules that expire or change by season.
Set credit limits and the exception path
Finance sets credit limits at the customer, customer group, or company level and decides which limits block submission of a new Sales Order or Sales Invoice. The team also names the role allowed to approve an exception once a limit is reached. Output: a credit limit schedule and an approval matrix that record who can override a block and under what documented conditions. Confirm how receivables aging is reported so the limit values come from current balances.
Assign roles, permissions and approvals
The implementer creates selling roles for sales reps, sales managers, credit controllers, and warehouse staff, then restricts visibility by territory, customer, or company where the business requires it. Document approvals for discounts, quotations above a value threshold, and any order that bypasses a credit block. Output: a role matrix tested with one user per role, showing that each user can complete their steps and is blocked from the others. Keep the matrix in version control so later changes are reviewed.
Configure delivery note and fulfilment settings
Decide whether a Delivery Note is required before a Sales Invoice can be created, whether partial fulfilment is allowed on Sales Orders, and how over-delivery and backorders are handled against stock. These settings change the posting path, so the team records each choice with its business reason. Output: a settings record approved by operations and finance that describes the order-to-invoice path for standard, partial, and drop-ship orders. Verify the chosen behavior against the current ERPNext documentation for your version.
Run an end-to-end test cycle
Testers run scripted scenarios from quotation through Sales Order, Delivery Note, and Sales Invoice, including a partial delivery, a credit-blocked order with an approved exception, a discount that triggers a pricing rule, and a return. Each run is checked against expected stock movements, ledger entries, and receivable balances. Output: a test log where every scenario has a recorded result, with defects logged and retested until accepted by finance and sales. Keep the test data set so it can be replayed after upgrades.
Go live with user training and support
The team loads production master data, cuts over open orders and receivables according to the agreed plan, and trains each role on its actual screens and approvals. Support contacts and a rule for handling urgent credit exceptions are published before the first live order. Output: a go-live checklist signed by the business owner, training attendance records, and a first-week review of posted invoices and blocked orders. Ask the partner to state what post-go-live support is included in the written scope.
Loading customers, items and open orders into ERPNext
Load masters before transactions. Customers, items and item prices must exist before open quotations and sales orders can reference them, so the import order matters more than the import speed. The ERPNext Data Import tool reads CSV or Excel files or public Google Sheets, starts from downloadable templates, and supports child table rows, which is how item lines on a sales order or price list entries are loaded. The ERPNext documentation advises importing only a few thousand records at a time, so split each file into batches, load one batch, check the results on screen, and only then start the next. Ask your implementer to confirm the template version against the ERPNext release you are running, since field names can change between versions.
Open quotations and sales orders need a deliberate cutover decision. Decide which documents carry over as live records and which are closed in the legacy system, then state the cutoff date in writing. Each open sales order that moves across should be checked for the customer, item, rate, quantity already delivered and quantity already invoiced, because those fields determine what remains to deliver and bill in ERPNext. Customer outstanding balances and open invoices are a finance question, not a sales one, so reconcile the receivables totals in the new system against the legacy ledger with the finance team before anyone starts issuing documents. Keep a signed reconciliation sheet as evidence for the cutover file.
What makes selling setup take longer or cost more
This table compares the factors that expand ERPNext selling work and the steps that keep each one contained. Read each row as a question to answer before asking for a quote, since most of the effort sits in pricing exceptions, master data quality and the stock and accounts links. The main takeaway is that a clean customer and item master and a short list of pricing rules usually matter more than the number of documents you configure.
| Driver | Why it adds effort | How to reduce it |
|---|---|---|
| Price lists and pricing rule exceptions | Each price list and each Pricing Rule with its own item, party, quantity, date or currency condition must be designed, tested and maintained as prices change. | Start with one standard price list and a few rules. Document which rule wins when several match, and retire rules that no longer apply. |
| Customer groups and credit tiers | Credit limits can be set per Customer, Customer Group and Company, so each tier needs an agreed limit, an approver and a test of the blocking behavior. | Limit tiers to the few groups finance actually manages. Set limits at group level and reserve customer-level exceptions for named accounts. |
| Integration with stock and accounts | Delivery, invoicing and stock posting depend on how the selling documents link to warehouses, the chart of accounts and tax templates. Mismatches surface only in test transactions. | Agree in writing whether a delivery note is required before invoicing, which warehouses serve which customers, and which income and tax accounts each item uses. |
| Multi-company or multi-currency selling | Each company needs its own accounts, price lists and credit limits, and each currency needs exchange rate handling and tax rules that match the invoicing entity. | Confirm the number of companies and currencies early. Build one reference configuration, then copy it, instead of designing each company from scratch. |
| Custom print formats and custom scripts | Quotations and invoices that must match a legal or brand layout need format work, and server-side logic needs testing and review on every upgrade. Server Scripts also need to be enabled on self-managed sites. | Begin with standard print formats and fields. Limit custom scripts to rules that cannot be met by configuration, and keep them in a version-controlled custom app. |
| Data quality of customer and item master | Duplicate customers, inconsistent item codes, missing units of measure or wrong tax categories create rework during testing and in every migrated sales order. | Clean and de-duplicate the customer and item lists before import. Import in batches using the Data Import templates, checking a sample of records after each batch. |
Questions buyers ask before configuring ERPNext selling
What drives the cost and effort of setting up ERPNext selling?
Cost follows the number of decisions the selling cycle forces: how many price lists and pricing rules you need, how credit limits map to customer groups and companies, whether delivery notes are required for each order type, and how many invoice and tax variants you run. Part of the cost is one-time (configuration, testing, training, data load) and part recurs (hosting, support, upgrades). Ask any partner for a fixed-scope quote that lists each setting, the test cases it will be checked against, and who is paid for what. The ERPNext pricing page describes self-hosting as free, so your main costs are infrastructure, configuration effort and support, not licences.
How long does ERPNext selling setup usually take?
Duration depends on how many order flows you have, how many pricing and credit rules you need, and how clean your existing customer and item data is. A single company selling one way can move quickly, while multi-company groups with discounts negotiated per customer take longer. No general duration is set here, so ask a partner to show the timeline in the written scope, with separate milestones for sample order testing, user acceptance and go-live. Treat any figure given without a scope as a starting assumption to test.
What does the work need from our team?
You need named decision owners for pricing, credit control, delivery and invoicing, because those settings encode business rules that a developer cannot decide for you. Provide a set of real sample orders covering standard sales, discounts, partial deliveries, returns and credit-held customers, plus your written approval rules for exceptions. Sales, finance and warehouse staff should each review the test results for their area before go-live. Confirm these responsibilities in the scope so delays are visible early.
Can our internal staff configure ERPNext selling themselves?
Yes, many of the selling settings are made through the ERPNext interface by administrators who understand the business process, including price lists, pricing rules and credit limits. The harder part is deciding the rules and testing that they behave correctly across documents, which benefits from someone who has configured the module before. Internal staff can own the configuration once they have a documented design, a test order set and a change process. Ask whether a partner will train your administrators and hand over the configuration record as part of the scope.
Do we need server scripts for selling, and what are the Frappe Cloud limits?
Most selling setup is done with standard settings and does not need server scripts. Use them only when a rule cannot be expressed in configuration. Since version 15, Frappe Framework disables Server Scripts by default, so you must enable them with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. If you need a script, plan for a dedicated bench or self-hosted deployment, and treat the script as code that needs review, testing and version control. Confirm the deployment model before designing any custom logic.
How do we upgrade ERPNext safely without breaking our selling setup?
Start by checking the supported versions page, because version 14 reached end of life on January 31, 2026, and both version 15 and version 16 have published support windows. Keep a staging copy of your site, export your customizations, rerun your sample order tests after each minor and major step, and review release notes for changes to selling documents. Frappe's supported versions policy also ties warranty coverage to a listed version and a matching Frappe Cloud support plan, so confirm that position before you upgrade. Schedule upgrades in planned windows with a rollback plan and a backup taken immediately before the change.
What goes wrong most often when a sales order flow is misconfigured?
The most common faults are pricing rules that apply to the wrong customer or quantity band, credit limits that block valid orders because the limit is set at the wrong level, and delivery settings that let invoices post before stock moves or the reverse. Each fault appears only in particular combinations, so test them with a fixed set of sample orders rather than a single happy path. Ask your partner which test cases cover pricing precedence, credit exceptions and partial fulfilment before accepting the design.
How selling connects to stock, accounts and other systems
Selling in ERPNext touches Stock and Accounts at specific points, and the setup decisions you make in the selling module determine where those points fall. A Sales Order records the commitment to the customer, but stock moves only when a Delivery Note is created, and whether that step is mandatory depends on the selling settings you choose. Before go-live, confirm with your own team which documents must be submitted before stock leaves the warehouse, and check how reserved quantities behave when a Sales Order is partly delivered. Reservations and delivery timing affect what sales can promise, so they belong in the same review as the warehouse design.
On the accounts side, a Sales Invoice posts to receivables and revenue accounts, and that posting is what finance will reconcile against payments. Credit limits sit on the boundary between selling and accounts: limits set at Customer, Customer Group or Company level can block a new Sales Order or Sales Invoice once the limit is reached, unless an authorized role approves the exception. Decide who holds that approval role and whether finance, not sales, owns it. Test a blocked order end to end with a sample customer before you rely on the control.
Login is the other connection that affects selling. ERPNext supports LDAP through LDAP Settings against Active Directory or OpenLDAP, with SSL/TLS options and automatic mapping of LDAP groups to ERPNext roles at each login, so role assignments for sales staff can follow directory groups. For OAuth or OpenID Connect, Social Login Key lets users sign in through configured providers or custom endpoints. Server Scripts that extend selling logic run Python on document events, and from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Confirm that setting in your environment and plan custom validations as code in a custom app if you cannot enable it. Marketplace and payment gateway connectors belong to the ERPNext integrations group, and each one should be checked for which orders, invoices and payment entries it creates.
Systems selling depends on in the rest of the platform
A selling cycle in ERPNext touches stock, accounts, sign-in and external channels. Each connection below moves different data, and each one changes who can create or approve a quotation, sales order or invoice. Confirm the behavior of each link in your own environment before you finalize the selling settings.
Stock module
Delivery Notes reduce stock in the warehouse the sales order names, and whether a Delivery Note is required before invoicing depends on how stock settings and the sales order are configured. Item availability, reserved quantities and valuation all come from the Stock module, so warehouse setup must be finished before selling goes live. Ask your team which warehouses sell, which items are serialized or batched, and whether partial deliveries are expected. Confirm the stock settings option that controls delivery note requirements against the current ERPNext documentation for your version.
Accounts module
Sales Invoices post receivables, revenue and tax entries to the chart of accounts, and credit limits read outstanding balances from the same ledger. Default income accounts, tax templates and the customer's receivable account must be set before the first invoice is submitted. Check how returns, credit notes and write-offs are posted, since these change the customer balance that feeds the credit check. Confirm posting behavior with your finance lead before the first test invoice.
LDAP login for role mapping
LDAP Settings let users sign in with corporate Active Directory or OpenLDAP accounts, and ERPNext maps directory groups to ERPNext roles at each login. Sales roles that can submit sales orders, approve credit exceptions or see margins should follow directory groups, not hand-assigned users. Test that a user removed from a group loses the matching role, and confirm the SSL/TLS options your directory requires. Review the LDAP integration documentation for the mapping behavior in your version.
Social Login Key
Social Login Key lets users sign in through providers such as Google, Microsoft or a custom OAuth or OpenID Connect endpoint. It handles authentication only, so the user's ERPNext roles and permissions still decide which quotations and invoices they can see. Confirm which identity provider your sales staff will use, whether external accounts are allowed to sign in at all, and how new accounts are created or linked. Check the current Frappe documentation for the provider settings your version supports.
Data import for price lists and customers
The Data Import tool loads customers, items, price list rates and other records from CSV or Excel files using downloadable templates. Imports suit the first load of price lists and customer masters, but the documentation advises importing only a few thousand records at a time, so large catalogs need batching. Check that customer groups, territories and currencies match before importing, because a mismatch leaves quotations without the right rates. Confirm the template version against your ERPNext release before you prepare the files.
Ecommerce and payment connectors
Ecommerce and payment connectors can push orders into ERPNext and send payment status back, which means sales orders may be created without a salesperson's quotation. Decide which system owns customer prices, tax, stock reservation and credit checks before enabling a sync, or the same order can be priced twice. Ask each connector vendor which documents it creates, which fields it writes and how failed syncs are retried. Confirm the sync scope in the connector's own documentation and in a test company before live orders flow.
Choosing a supported version before configuring selling
Confirm the ERPNext and Frappe Framework version before you build any selling configuration, because the answer decides how long your quotation, pricing and invoicing setup stays supported. According to Frappe's supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. A selling design built on a version that is near or past end of life means a platform upgrade will eventually land on top of live price lists, pricing rules and credit limits. Pick the version that covers your planned go-live and your expected operating period, then write that date into the project plan.
Warranty coverage is a separate question from technical support. Frappe's supported versions policy states that customers must run a listed version and hold a Frappe Cloud support plan that matches it to receive warranty coverage from Frappe. If you self-host, confirm with Frappe and with your implementation partner exactly which support arrangement applies to your environment, and get the answer in writing before the contract is signed. Ask who is responsible for a defect in a pricing rule that was configured correctly but behaves differently after a patch.
Minor releases arrive frequently on both supported major versions, so a configuration that passed testing last month may not behave the same after the next update. Build a short regression script for the selling cycle covering a quotation with a pricing rule, a sales order, a partial delivery, an invoice that exceeds a credit limit and an approved exception. Run it on a staging copy before every minor update, and record the ERPNext version tested. Treat the script as a standing deliverable, not a one-time acceptance step.
How DeployOpen scopes and delivers ERPNext selling setup
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and ERPNext selling setup follows the same method. We agree the selling cycle, pricing and approval rules in writing before build starts, then hand over a configured system your team can run.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists the quotation, sales order, delivery note and invoice flows you need configured.
- We map price lists, pricing rules, credit limits and approval exceptions to named roles in your organization.
How we build
- We configure selling settings, including whether a delivery note is required before invoicing, against your fulfilment process.
- We build pricing rules and credit limits, then test them with sample quotations and orders from each customer group.
- We check partial fulfilment and partial invoicing scenarios on a non-production site before go-live.
How we hand over
- You receive a written record of settings, pricing rule logic, credit limit levels and the roles that can approve exceptions.
- We document the test cases used, the results and the open items you must confirm with your sales and finance leads.
- Your administrators are trained on maintaining price lists, pricing rules and customer credit limits after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Changes to pricing or credit policy are scoped and tested before they reach your production site.
- Upgrade planning for ERPNext selling workflows is confirmed against the supported versions your team chooses to run.
