Business details

A customer's Business Name, EIN, Shipping Address and Billing Address are edited on the Edit Customer Form (customer page → Edit Info). These details belong to the restaurant's own record. Saving changes them for the restaurant itself and for every other supplier it buys from. Only the Customer Ref ID on the same form is private to the supplier. The EIN or Tax ID document uploaded on the form is shared the same way.

Who uses it

• Supplier staff correct a customer's name, addresses and EIN, and upload the EIN or Tax ID document.
• Restaurants enter the same details in the restaurant app when they sign up.

How it works

Opening the form

On the customer's page, Edit Info opens "Edit Customer Form", described as: "Edit this information for your internal view of the customer. All orders will be processed using the information entered here. The customer's original information from the app remains unchanged."

The description is not accurate today

The last sentence is not what happens: saving does change the restaurant's own details, as seen by the restaurant and every supplier. See What's private and what's shared.

Edit Info is shown to roles with full customer access, and hidden for a customer marked inactive.

The fields

Section	Field	Rules	Private to this supplier?
Business Information	Business Name	Required: "Business Name is required". Spaces trimmed	No, shared
	EIN	Optional. Clearing it removes the EIN. An EIN can belong to only one business in Clipp (verify the message)	No, shared
	Customer Ref ID	Optional, free text. Only shown once the customer is connected	Yes
Shipping Address	Address, city, state, ZIP		No, shared
Billing Address	"Billing address same as shipping" checkbox, or a separate address		No, shared
Documents	"Upload EIN or Tax ID document". "Supported file formats: PDF, JPG, PNG (Max 5 MB)"	Over 5 MB: "File size exceeds 5MB limit"	No, shared

Buttons: Update ("Updating..." while saving) and Cancel. Update is disabled until something changes, while saving, and when the form is read-only.

Messages: "Customer updated successfully" / "Failed to update customer".

When the form is read-only

If the supplier invited a restaurant that already had a Clipp account, and it hasn't accepted yet, every field is disabled. Its details belong to the restaurant until it connects. The same applies to the document upload and delete buttons.

Who else a change reaches

	Before	After Supplier A saves "Kulu Lower Manhattan"
Supplier A's customers list, new orders	Kulu Desserts Lower East Side	Kulu Lower Manhattan
Supplier B's customers list, new orders	Kulu Desserts Lower East Side	Kulu Lower Manhattan
The restaurant's own app	Kulu Desserts Lower East Side	Kulu Lower Manhattan
Existing orders and their invoices (see Order snapshot)	Kulu Desserts Lower East Side	Unchanged
Bookkeeping rows already recorded	Kulu Desserts Lower East Side	Unchanged (verify)
Messages to the restaurant		None are sent about the edit

EIN or Tax ID document

• One document is shown per customer. Uploading another replaces it.
• The document is stored against the restaurant, so every supplier sees the same file, and any supplier can replace or delete it.
• If the restaurant uploads its own document, it replaces the one suppliers see too (verify).

Calculations

None.

Where it shows up

Customer detail header (name, address, EIN) · Customers list · New order dialog · Invoice PDF "Ship To" and "Bill To" via the snapshot · Catalogs, chat, sales report (name).

Permissions

Action	Who
See Edit Info	Roles with full customer access (Admin, Clerk by default). Hidden for inactive customers
Save the form	Any supplier staff connected to, or inviting, the customer (the server doesn't check the role; see Known limitations)
Edit when the restaurant had an account and hasn't accepted yet	Nobody. The form is read-only

Decisions

• One "Edit Customer Form" for name, EIN, addresses and the Customer Ref ID. (#1907, #1909)
• Billing address is separate from shipping, defaulting to "same as shipping". (#1908)
• A restaurant that already had an account owns its details until it accepts. The supplier can't change someone else's existing business before being connected.

Known limitations

• Changes aren't private. Name, addresses and EIN changes reach the restaurant and every other supplier, despite the form's description. Private overrides (dual-data) aren't built (product decision needed: build them, or change the wording).
• The EIN document is shared. One supplier can replace or delete a document another supplier relies on.
• Read-only roles can open the edit page, and the server accepts a save from any of the supplier's staff.
• A Customer Ref ID typed while inviting an existing restaurant is lost. It isn't kept when the restaurant accepts.

FAQ

I renamed a customer. Will it change their old invoices? No. Invoices print the customer details captured on the order. See Order snapshot.

Will the restaurant see the name I gave them? Yes, today it will. The change is to the restaurant's own record. See the warning above.

Why can't I edit this customer's details? You invited a restaurant that already had a Clipp account, and it hasn't accepted. Once it accepts, the form opens.

Can I keep my own name for a customer without changing theirs? Not yet. Use the Customer Ref ID for your own code. A private name is part of the planned dual-data work.

Specs

These specs don't match the app

• DDEB-003, DDEB-004: "After onboarding, editing business fields updates only supplier records". In the app it updates the restaurant's own record.
• DDTX-001 – DDTX-006: "Supplier and restaurant maintain independent EIN/Tax ID document records". In the app there is one shared document per restaurant, and the DDTX-004 error doesn't exist.

DDEB-001 and DDEB-002 (before onboarding, edits update both) match.

edit-business-info.feature

# prefix: DDEB
Feature: Editing restaurant business information
    A supplier can edit a restaurant's business fields through the Clipp app.
    Before onboarding, edits update both supplier and restaurant records.
    After onboarding, only supplier records are updated.

Background:
    Given supplier "Miguel Supplier Test" has a restaurant "John Pizza III" with the following business information:
        | Business Name                   | John Pizza III     |
        | Business Tax Id                 | 45456644           |
        | Business Shipping Full Address  | 123 Wall st        |
        | Business Shipping City          | Brooklyn           |
        | Business Shipping State         | NY                 |
        | Business Shipping Zip           | 11222              |
        | Business Billing Full Address   | 123 Wall st        |
        | Business Billing City           | Brooklyn           |
        | Business Billing State          | NY                 |
        | Business Billing Zip            | 11222              |

Rule: Before onboarding, editing business fields updates both supplier and restaurant records

    Scenario Outline: DDEB-001 Edit the restaurant's <field>
        Given the restaurant has not completed onboarding
        When the supplier edits the restaurant's <field> to "<new_value>"
        Then the restaurant's <field> is updated to "<new_value>"
        And the supplier's customer records reflect the updated <field>

        Examples:
          | field                  | new_value       |
          | Business Name          | John Pizza IV   |
          | Business Tax Id        | 45456645        |
          | Shipping Full Address  | 456 Main st     |
          | Shipping City          | Manhattan       |
          | Shipping State         | NJ              |
          | Shipping Zip           | 10001           |
          | Billing Full Address   | 456 Main st     |
          | Billing City           | Manhattan       |
          | Billing State          | NJ              |
          | Billing Zip            | 10001           |

    Scenario: DDEB-002 Use billing address as shipping address
        Given the restaurant has not completed onboarding
        When the supplier sets the billing address as the shipping address
        Then the supplier's shipping address is updated to match the billing address
        And the restaurant's shipping address is updated to match the billing address

Rule: After onboarding, editing business fields updates only supplier records

    Scenario Outline: DDEB-003 Edit the restaurant's <field>
        Given the restaurant has completed onboarding
        When the supplier edits the restaurant's <field> to "<new_value>"
        Then the supplier's customer records reflect the updated <field>
        And the restaurant's <field> remains unchanged

        Examples:
          | field                  | new_value       |
          | Business Name          | John Pizza IV   |
          | Business Tax Id        | 45456645        |
          | Shipping Full Address  | 456 Main st     |
          | Shipping City          | Manhattan       |
          | Shipping State         | NJ              |
          | Shipping Zip           | 10001           |
          | Billing Full Address   | 456 Main st     |
          | Billing City           | Manhattan       |
          | Billing State          | NJ              |
          | Billing Zip            | 10001           |

    Scenario: DDEB-004 Use billing address as shipping address
        Given the restaurant has completed onboarding
        When the supplier sets the billing address as the shipping address
        Then the supplier's shipping address is updated to match the billing address
        And the restaurant's shipping address remains unchanged

ein-tax-id-documents.feature

# prefix: DDTX
Feature: EIN/Tax ID documents
    Suppliers and restaurants maintain independent EIN/Tax ID document records.
    Each party manages their own version of the document. When a supplier
    has not uploaded their own version, they see the restaurant's document.

Rule: Supplier and restaurant maintain independent EIN/Tax ID document records

    Scenario: DDTX-001 Supplier uploads a business EIN/Tax ID document
        Given the supplier has not uploaded a business EIN/Tax ID document
        When the supplier uploads a business EIN/Tax ID document
        Then the supplier can see the document in their customer records
        And the supplier receives a success confirmation
        But the restaurant cannot see the supplier's document

    Scenario: DDTX-002 Supplier replaces their own EIN/Tax ID document
        Given the supplier has uploaded a business EIN/Tax ID document
        When the supplier uploads a new business EIN/Tax ID document
        Then the previous document is replaced with the new one
        And the supplier can see the updated document in their customer records
        And the supplier receives a success confirmation
        But the restaurant cannot see the supplier's document

    Scenario: DDTX-003 Supplier deletes their own EIN/Tax ID document
        Given the restaurant has completed onboarding
        And the supplier has uploaded a business EIN/Tax ID document
        And the restaurant has uploaded their own business EIN/Tax ID document
        When the supplier attempts to delete their business EIN/Tax ID document
        Then the supplier's document is removed
        And the supplier now sees the restaurant's document in their customer records
        And the supplier receives a success confirmation

    Scenario: DDTX-004 Supplier cannot delete when no own version exists
        Given the supplier has not uploaded a business EIN/Tax ID document
        And the restaurant has uploaded their own business EIN/Tax ID document
        When the supplier attempts to delete the business EIN/Tax ID document
        Then the supplier receives an error

    Scenario: DDTX-005 Restaurant's EIN document upload affects only suppliers without their own version
        Given the restaurant has completed onboarding
        And supplier "Miguel Supplier Test" has not uploaded their own business EIN/Tax ID document
        And supplier "Another Supplier" has uploaded their own business EIN/Tax ID document
        When the restaurant uploads their own business EIN/Tax ID document
        Then supplier "Miguel Supplier Test" can see the restaurant's document in their customer records
        And supplier "Another Supplier" continues to see their own document
        But the restaurant cannot see any supplier's document

Rule: EIN/Tax ID documents always follow the independent model regardless of onboarding status

    Scenario: DDTX-006 Supplier uploads EIN document before restaurant onboarding
        Given the restaurant has not completed onboarding
        When the supplier uploads a business EIN/Tax ID document
        Then the supplier can see the document in their customer records
        And the supplier receives a success confirmation
        But the restaurant does not see the supplier's document