Step-by-step instructions
A manager can create a supplier with multilingual name, tax and registration identifiers, contacts, address, logo, platform-account email, payment account details, and a saved list row that later connects to purchasing, receiving, reports, and AI agent context.
Use the interactive screenshot walkthrough first. Switch steps with the step dots, then read what to fill and why it matters.
Fields on this screen
Suppliers list
How to fill: Open Suppliers and check existing rows before adding a new profile.
Why: Duplicate suppliers split purchase history, contacts, invoices, and reporting.
Add
How to fill: Click Add in the top-right corner to open a new Supplier form.
Why: The form creates a new editable supplier draft.
Supplier name
How to fill: Type the supplier name in the active interface language.
Why: Staff identify vendors by this name in lists, purchases, receiving, and reports.
Name translations
How to fill: Open the translation control and fill every enabled language when the company works multilingual.
Why: Translated supplier names keep reports and AI answers readable for each interface language.
Tax number
How to fill: Enter the supplier tax identifier only when the supplier has one.
Why: Accounting and invoice checks depend on the exact tax ID.
Registration number
How to fill: Enter the supplier registration or vendor number.
Why: This links the SABSUS supplier profile to legal and external accounting records.
Comment
How to fill: Add a short internal note such as delivery window, ordering rule, or credit term.
Why: Managers need operational context without mixing it into address or contact fields.
Contact type dropdown
How to fill: Open the contact type list and choose Phone, Email, WhatsApp, Telegram, Instagram, Linkedin, Facebook, or Other.
Why: The type tells staff and automation how to use the value.
Contact value
How to fill: Enter the contact value exactly as staff should use it, then click Add.
Why: Incomplete contact values make supplier ordering and claims slower.
Supplier address
How to fill: Open the address form and fill address line, address line 2, address type, city, state, ZIP, country, door code, and comment where applicable.
Why: Receiving, pickup, mail, and invoice workflows need structured address details.
Company logo
How to fill: Attach the supplier logo or a clear recognizable image.
Why: Visual identity helps managers choose the right supplier quickly.
Create an account on the platform
How to fill: Turn this on only when the supplier should log into SABSUS.
Why: Internal-only suppliers do not need a login account.
Email for registration
How to fill: Enter a unique supplier email if platform access is enabled.
Why: The account creation function uses this email for login and recovery.
Add supplier account
How to fill: Turn this on when invoices, payouts, or payment documents need bank details.
Why: Bank data should be structured instead of buried in comments.
Bank details
How to fill: Fill account number, settlement account, bank code, and bank name.
Why: Accounting exports and payment preparation depend on exact structured bank values.
Save
How to fill: Save after name, identifiers, contacts, address, logo, platform email, and bank details are reviewed.
Why: Only saved supplier profiles can be used reliably in lists, purchasing, receiving, reports, and agents.
Verify row
How to fill: Return to Suppliers and search for the saved supplier.
Why: List verification proves the profile was written and loaded back from the real database.
Common mistakes
- Creating a supplier before checking whether the vendor already exists.
- Typing the supplier name only in one language when the company uses multiple active interface languages.
- Mixing tax number and registration number.
- Putting phone, email, and chat handles into one unstructured comment instead of Contacts.
- Saving an address without city, state, ZIP, or country when logistics or accounting will need it.
- Creating a platform account with the owner's email instead of the supplier's unique email.
- Turning on bank details and leaving account fields as zero or placeholder values.
- Using the supplier profile as a stock receiving document; receiving belongs in supply workflows and references the supplier.
AI Agent Field Reference for implementation
This block is intentionally below the human instructions. It explains storage names and downstream dependencies for automation, support, and future AI agents.
| Field | Stored as | Purpose | Why it matters |
|---|---|---|---|
| Supplier profile ID | users/{supplierId}.uid / document id | Stable supplier profile identifier in Firestore. | Purchasing, receiving, support, reports, imports, and AI agents need a stable supplier reference instead of relying on the visible name. |
| Company | users.CompanyID | Company workspace that owns the supplier. | Prevents suppliers from different workspaces from appearing in the wrong procurement flow. |
| Position | users.Position = Supplier | Marks the user record as a supplier profile. | The Suppliers list filters Firestore users by CompanyID and Position, so the value must be exact. |
| Supplier name translations | users.name[] | Multilingual supplier name stored as language/text objects. | Staff screens, reports, imports, receiving documents, and AI explanations need the supplier name in the active language. |
| First / last name fallback | users.Firstname / users.Lastname | Fallback display fields used by table columns. | Some list columns still read first and last name, so supplier rows should not rely only on translated name objects. |
| Logo | users.Photo.image | Supplier logo or recognizable image. | The list and edit form become easier to scan, especially when several suppliers have similar names. |
| Tax number | users.TaxID | Supplier tax identifier. | Invoices, accounting review, supplier statements, and compliance workflows need this value when applicable. |
| Registration number | users.Registration | Business registration or vendor number. | Helps match supplier records to legal documents, contracts, and external accounting systems. |
| Comment | users.Comment | Internal note about the supplier. | Managers can store delivery windows, preferred ordering rules, credit terms, or quality notes without showing them to customers. |
| Contacts | users.Contacts[] / users.contact[] | Structured supplier contact methods such as phone, email, WhatsApp, Telegram, Instagram, or other. | Purchasing and support need the right channel for orders, invoices, claims, and urgent delivery questions. |
| Contact type | users.Contacts[].name | Selected communication channel. | A phone number, email, Telegram handle, and WhatsApp contact should not be treated as the same type of data. |
| Contact value | users.Contacts[].value | Actual phone, email, handle, or URL. | The value must be copyable and actionable for managers and future automation. |
| Address | users.Address[] | Supplier physical or mailing address objects. | Receiving, pickup, legal documents, delivery planning, tax context, and support explanations depend on supplier address data. |
| Address line | users.Address[].address | Street address or main address line. | The primary address must identify where goods, invoices, or documents should be sent. |
| Address line 2 | users.Address[].Apartment | Suite, dock, unit, office, or extra address line. | Delivery and receiving teams often need dock, gate, or office details. |
| Address type | users.Address[].name | Label such as warehouse, office, billing, or factory. | Staff should know whether an address is for receiving, documents, pickup, or payments. |
| City | users.Address[].city | Supplier city. | Used for logistics, regional reporting, and address validation. |
| Region / state | users.Address[].state | State, province, or region. | Needed for complete addresses and regional tax or logistics rules. |
| Postal code | users.Address[].zipCode | Postal or ZIP code. | Shipping, accounting, and address validation often require it. |
| Country | users.Address[].country | Supplier country. | International suppliers may use different tax, currency, and delivery assumptions. |
| Door code | users.Address[].Code-door | Door, gate, or access code. | Receiving staff can find the right entrance without storing it in an unstructured comment. |
| Address comment | users.Address[].Comment | Operational note for the address. | Keeps address-specific delivery notes separate from the supplier-level comment. |
| Create platform account | users.email + auth account | Whether the supplier should receive a SABSUS login. | Only enable it when the supplier needs platform access; otherwise keep supplier data internal. |
| Registration email | users.email | Email used to create or identify the supplier account. | The email must be unique and correct because account creation and recovery depend on it. |
| Last interface | users.LastInterface = Supplier | Default interface after login when a supplier account is created. | Supplier users should open the supplier-facing context, not the owner or staff interface. |
| Notifications | users.NotificationPUSH / NotificationSMS / NotificationEmail | Supplier notification preferences. | Automation and communication workflows need to know which channels may be used. |
| Add supplier account | users.Account | Nested payment account object for supplier invoices and payouts. | Bank data should be structured only when the business needs supplier payment documents. |
| Account number | users.Account.NumberAccount | Supplier bank account number. | Invoices, payment files, and accounting exports may need the account number. |
| Settlement account | users.Account.Settlementaccount | Settlement or clearing account. | Some countries and banks require this extra account field for payment documents. |
| Bank code | users.Account.CodeBIC | Bank routing, BIC, SWIFT, or local bank code. | Payments and accounting integrations need the correct bank code. |
| Bank name | users.Account.NameBank | Readable bank name. | Managers can verify bank details without decoding routing numbers. |
| Created / updated | users.created_time / users.LastDate | Supplier creation and activity timestamps. | Support and AI agents can see whether supplier data is fresh or stale. |
| Supplier deliveries | supplies.supplier | Supplier reference used by receiving or supply documents. | Once supplier profiles exist, stock receiving can point to the correct vendor. |
| Security rule | company.security.IfAddSeppluers | Manager-password rule for supplier deliveries. | Supplier delivery actions affect inventory, cost, and purchasing reports. |
| Reload behavior | FFAppState().suppliers / suppliers() action | Client-side supplier cache loaded from Firestore. | After backend changes, the app must reload suppliers so lists and selectors show current data. |
Related guides
Use these guides to connect this section to adjacent SABSUS workflows.