Privacy Policy

1. Introduction

PharmaERP (“PharmaERP”, “we”, “us”, or “our”) is a multi-tenant pharmaceutical distribution and field-force execution platform. It includes a web application for administrators and managers and a mobile application for medical representatives and field teams.

This Privacy Policy explains what information PharmaERP collects, how it is used, who can access it, and the choices available to users. It is written to reflect the current product behaviour of the web app, mobile app, and backend API.

PharmaERP is an enterprise / B2B product. Accounts are created for employees and authorized users of customer organizations (“Customer Organizations”). Customer Organizations control much of the business data entered into their tenant.

2. Scope

This Policy applies to:

• The PharmaERP web application
• The PharmaERP Mobile application (Android / iOS)
• Related backend APIs and optional media storage used by those applications

It does not apply to third-party websites or apps that we do not operate (for example, Google Maps when opened outside PharmaERP), except where we describe how PharmaERP uses those services.

3. Information We Collect

We collect information in three ways:

• Information you or your organization provide (account setup, CRM records, orders, plans)
• Information collected automatically from devices (location during field work, device identifiers, app diagnostics related to tracking)
• Information generated by product use (attendance events, visit logs, audit logs, sync and notification status)

PharmaERP does not operate a consumer social network and does not sell personal information.

4. Personal Information

For authorized users (employees / field staff), we typically process:

• Name, work email address, and phone number (if provided)
• Password (stored as a one-way hash; never returned by the API)
• Role, permissions, manager hierarchy, and territory assignments
• Login metadata such as last login time and last login IP address
• Optional profile photo / avatar when media upload is enabled
• Employment-related operational data such as attendance, expenses, and payroll records managed by your organization

Authentication uses JSON Web Tokens (access and refresh tokens). On the web app, tokens are stored in browser local storage. On the mobile app, tokens and a device identifier are stored in the device secure store (Keychain / Keystore).

5. Location Information

Location is central to field-force features. PharmaERP requests location permission only for operational purposes described below. Precise location is collected when the relevant feature is used and when your organization’s configuration enables it.

Foreground location

While you use the mobile app, PharmaERP may read your current location to validate attendance check-in / check-out, verify visits near doctor or call-point coordinates, and show maps. Check-in and check-out records may store latitude, longitude, and GPS accuracy.

Background location and live tracking

If your organization enables live tracking / manager live map features, the mobile app may continue to collect location while you are checked in, including when the app is in the background. On Android this uses a foreground service notification; on iOS it may require “Always” location permission. Location updates are intended to stop when you check out. Managers with appropriate permissions can see your last known position on the live tracking screen (not a continuous video feed).

Before background sharing is enabled, the mobile app presents an in-app consent explanation. You can revoke background location access in your device settings at any time; doing so may limit attendance or live-tracking features required by your employer.

What location samples include

Live-tracking heartbeats may include latitude, longitude, accuracy, optional speed and heading, capture time, whether the sample came from foreground or background, optional battery percentage, and a client identifier used for reliable sync. Samples may be quality-filtered (for example, low-accuracy points may be kept for route history but not shown as the live pin).

Attendance validation, route history, and check-in verification

• Attendance validation: distance from a configured check-in point, call point, or policy radius may be evaluated and stored with the attendance record.
• Visit verification: when a doctor location is verified, visit completion may record distance from that location and a geofence result (inside / outside / not applicable).
• Route history: historical heartbeat trails may be shown to authorized managers for a selected day or period, including replay on maps.
• Territories and geofences: organizations may configure territory boundaries, call points, and geofence-related map features.

6. Device Information

The mobile app collects device information needed for security and operations:

• A stable device identifier generated on first launch
• Platform (iOS / Android), brand, model, OS version, and app version
• Optional Expo push notification token when notifications are enabled
• Optional tracking diagnostic events used to analyze GPS / sync gaps (retained on a time-limited basis)

If your organization enables device control, login may be limited to a bound device. Changing devices can require an administrator-approved device-change request.

7. Business Data

PharmaERP stores business and operational records entered by Customer Organizations, including orders, inventory, deliveries, payments, settlements, ledgers, procurement, targets, weekly and daily plans, expenses, announcements, and related reports. This data is processed to provide the ERP and field-force services your organization has licensed.

8. Doctor & Pharmacy Data

Customer Organizations may store professional contact and CRM data about doctors, pharmacies, distributors, and suppliers — for example names, specialty, phone numbers, email addresses, addresses, coordinates, territory assignment, visit targets, and professional registration numbers (such as PMDC). Doctor records may include an approximate patient count as a number; PharmaERP does not provide a patient medical-records module and is not designed to store patient health records.

Customer Organizations are responsible for having a lawful basis to collect and use this professional contact information in their markets.

9. Attendance Data

Attendance records may include:

• Check-in and check-out times and sources
• Status, late minutes, notes, and approval workflow state
• GPS coordinates and accuracy at check-in / check-out
• Distance from required check-in location and location-policy metadata
• Optional attendance selfie media when your organization enables media upload features

Managers and administrators with the appropriate permissions can view team or company attendance according to role-based access controls configured for the tenant.

10. Route History

When live tracking is used, location samples form a historical trail. Authorized managers may view route history and replay paths on maps for operational review (coverage, plan execution, and quality of GPS samples). Retention of heartbeat data is time-limited (see Data Retention).

11. Live Tracking

Live tracking is an organization-configurable feature. When enabled and while a field user is checked in, the mobile app periodically sends location heartbeats to PharmaERP servers. Authorized managers can view last-known positions on a live map. Heartbeats may also be delivered through an internal realtime channel to keep the manager map up to date.

Live tracking is not continuous video surveillance. Displayed positions can become stale if the device loses connectivity, GPS quality is poor, or permissions are revoked.

12. Camera & Media

When media features are enabled by configuration, PharmaERP may use the device camera or photo library to capture attendance selfies, visit photos, expense receipts, product visuals, and profile images. Files are uploaded through the API to object storage (Cloudflare R2 when configured) and referenced as media assets linked to the relevant record.

The Android build may declare a microphone permission because it is included with the camera SDK. The current PharmaERP product flows use the camera for still images / attachments; they are not designed as an audio-recording product feature.

13. How We Use Information

We use information to:

• Authenticate users and enforce role-based access and device-binding policies
• Operate ERP workflows (orders, inventory, finance, CRM, planning, visits)
• Validate field attendance and visit execution
• Provide live tracking and route history to authorized managers when enabled
• Sync offline mobile actions when connectivity returns
• Send push and in-app notifications when enabled
• Maintain audit logs and security records (including IP addresses associated with actions)
• Host and deliver media files when media upload is enabled
• Improve reliability of location and sync features using limited diagnostic events
• Comply with legal obligations and enforce our agreements with Customer Organizations

14. Data Sharing

We share information only as needed to operate the service:

• Within a Customer Organization tenant, according to roles and permissions (for example, managers viewing team attendance or live location)
• With infrastructure and service providers that process data on our behalf (database hosting, object storage, maps, push delivery, application hosting)
• When required by law, regulation, or valid legal process
• In connection with a corporate transaction, subject to appropriate safeguards

We do not sell personal information and do not share it for cross-context advertising.

15. Third-Party Services

PharmaERP relies on the following categories of third-party services as implemented today:

• MongoDB Atlas — primary application database (including TTL indexes used for some time-limited collections)
• Cloudflare R2 — media object storage (S3-compatible API) when media upload is enabled for the deployment
• Google Maps Platform — interactive maps, geocoding, places autocomplete, routing / distance services, and map tiles
• Expo — mobile runtime and push notification delivery (Expo Push / related Expo services)
• Application hosting providers used to run the API and web application

Redis may be present in the product as an optional infrastructure component (for example, heartbeat rate limiting or multi-node realtime fan-out). It is only used when explicitly configured with a Redis connection URL. In the current deployment Redis is not configured, so PharmaERP does not send data to a Redis service.

These providers process data under their own terms and security practices. Map deep links that open the Google Maps application or website are subject to Google’s terms.

PharmaERP’s current implementation does not integrate consumer advertising SDKs, Stripe payments processing, or third-party email/SMS marketing providers as part of the core product stack described in this Policy.

16. Data Security

We apply technical and organizational measures appropriate to an enterprise application, including:

• Password hashing with bcrypt (via bcryptjs) before passwords are stored
• JWT access tokens and refresh tokens for sessions; on mobile, refresh tokens are stored server-side as SHA-256 hashes (the raw refresh token is not kept in the database)
• Permission checks on API routes
• Tenant (company) scoping of data access
• Secure storage of mobile auth secrets on device
• Optional device binding to reduce unauthorized device use
• Transport of media via authenticated upload flows and short-lived signed access URLs when Cloudflare R2 (or equivalent object storage) is enabled
• Application and audit logging for security-relevant actions

No method of transmission or storage is completely secure. Customer Organizations should also apply strong password practices, limit admin privileges, and manage employee offboarding promptly.

17. Data Retention

Retention depends on data type and organization settings:

• Live-tracking heartbeats: the active (hot) collection has a MongoDB TTL index of approximately 90 days on capture time. Organization settings (typically 7–365 days) may also archive older samples into a longer-term store used for compliance and route history; that archive collection has no automatic TTL purge in the current product
• Tracking diagnostics: MongoDB TTL of approximately 90 days
• Media assets: classified as temporary or permanent; temporary media may expire according to company retention settings for check-in, visit, or expense media
• Core business records (orders, ledgers, CRM, attendance history): retained for as long as the Customer Organization maintains the tenant and applicable legal/accounting needs require
• Soft-deleted records may remain in the database in a deleted state rather than being immediately erased

18. User Rights

Depending on your jurisdiction and your relationship with the Customer Organization, you may have rights to access, correct, update, restrict, or delete personal information, or to object to certain processing.

Because PharmaERP is provided to organizations, many requests should start with your employer or the organization’s administrator (who controls user accounts and much of the tenant data). You may also contact us using the details in Contact Information. We will coordinate with the relevant Customer Organization where appropriate.

19. Children’s Privacy

PharmaERP is a workplace tool intended for adults acting in a professional capacity. It is not directed to children, and we do not knowingly collect personal information from children.

20. International Transfers

PharmaERP uses cloud infrastructure and third-party processors (including database hosting, object storage, maps, push delivery, and application hosting). Depending on where you and your organization are located, personal information may be processed in countries other than your own. Where required, we and our Customer Organizations rely on appropriate contractual and technical safeguards for such transfers.

21. Cookies and Local Storage

Web application

• Local storage: authentication tokens and certain UI/workflow caches (for example visit drafts and map display preferences)
• Cookies: theme / layout settings and color preference used by the UI shell
• Session storage: limited UI preferences in admin attendance screens

Mobile application

• Secure store: access token, refresh token, device identifier
• SQLite: offline queue (outbox), cached configuration, and offline attendance/visit data for synchronization
• AsyncStorage: theme preference

These technologies are used for authentication, offline reliability, and user interface preferences — not for third-party advertising.

22. Account Deletion

PharmaERP does not currently provide an in-app self-service “Delete my account” button for end users. User accounts are managed by Customer Organization administrators. Administrators can deactivate accounts so users can no longer sign in while preserving historical business records (such as orders and attendance) that the organization needs.

To request deletion or deactivation of your PharmaERP user account:

• Contact your organization’s PharmaERP administrator first, or
• Email asad.khan.achakzie@gmail.com with the subject “Account deletion request”, your full name, work email used for PharmaERP, and organization name

We will work with the Customer Organization to deactivate the account and address deletion or anonymization where legally required and technically feasible, noting that some records may be retained for legitimate business, security, or legal reasons.

On a device, signing out clears session tokens from secure storage. Uninstalling the app removes local caches on that device but does not by itself delete server-side records.

23. Changes to this Policy

We may update this Privacy Policy when product behaviour or legal requirements change. The “Last updated” date at the top of this page will be revised when changes are published. Material changes may also be communicated through the product or to Customer Organization administrators.

24. Contact Information

Questions about this Privacy Policy or PharmaERP privacy practices can be directed to: