1. Добавляете товары
Сканируете штрихкоды или быстро ищете. Строки появляются с названием, ценой, количеством, суммой — точно как в обычном кассовом чеке.
С того же экрана POS, на котором выбиваете обычный чек. Клиент просит счёт на компанию — выбираете опцию e-Factura, сканируете или вводите IDNO, система автоматически подтягивает данные компании из базы SFS и отправляет документ в портал e-Factura SFS через API. Подпись остаётся ответственностью оператора согласно процедуре SFS. Без единого захода в портал SFS ради текущих данных.
Процесс спроектирован так, чтобы не прерывать обычную продажу — кассир не покидает экран POS, не открывает другую вкладку, не запоминает пароли SFS.
Сканируете штрихкоды или быстро ищете. Строки появляются с названием, ценой, количеством, суммой — точно как в обычном кассовом чеке.
В процессе фискальной выписки, перед подтверждением чека, выбираете опцию e-Factura. Остальное — автоматически.
Сканируете IDNO камерой планшета или вводите. Система делает запрос в базу SFS и автоматически заполняет название, адрес и фискальный код — вручную данные клиента вводить не нужно.
Система применяет корректные ставки TVA к каждой строке (8% / 12% / 20% / 0% / без TVA) в зависимости от товара, а номер счёта идёт по порядку, без пропусков в серии.
Одним кликом счёт уходит черновиком в портал e-Factura SFS через API, используя настроенные в платформе учётные данные. Подпись остаётся ответственностью оператора согласно процедуре SFS — мы обеспечиваем только отправку.
За несколько секунд приходит ответ от SFS. Оператор получает уведомление через открытие в UI только что созданного внутреннего счёта, остаток списывается по строкам счёта, журнал SFS обновляется.
Счёт не «исчезает» после отправки — система отслеживает статус, пока он не станет окончательным, и сигнализирует о любых необходимых действиях.
После отправки счёт попадает в одно из состояний: Pending acceptance (ждёт покупателя), Accepted (покупатель подтвердил → счёт окончательный) или Rejected (покупатель отказал с причиной — решаете: корректировка + повторная отправка или аннулирование). Система синхронизирует статус с SFS автоматически.
Клиент вернул товар или вы поздно обнаружили ошибку? Запрос на аннулирование или сторнирование следует процедуре SFS и отслеживается полуавтоматически в платформе — система показывает статус на каждом шаге, решение остаётся за оператором. Полный аудит: кто, когда, причина.
Если SFS отклонил (редко — по мета-валидациям), получаете сообщение с точным полем, которое не соответствует формату. Исправляете → «Отправить повторно» → процесс возобновляется с отправки. Без необходимости пересобирать весь чек.
Не всякий B2B — это простая продажа на компанию. Вот задокументированные ситуации, которые процесс покрывает.
Если IDNO покупателя нет в базе SFS, мы получаем ограничение от SFS, и счёт не может быть выставлен на этого покупателя. Решение = покупатель регистрируется, либо выбираете другой способ продажи (простой фискальный чек, без e-Factura).
Самый частый случай в малом магазине: кто-то приходит и просит счёт на компанию работодателя. Кассир выбирает между e-Factura (на IDNO) ИЛИ простым фискальным чеком — оба на одном документе не выставляются. Для e-Factura сканирует IDNO, подтверждает, занимает несколько десятков секунд.
Мы не создаём периодически файл выгрузки. Бухгалтер может получать счета через API ERP — по индивидуальному запросу мы можем построить логику периодической выгрузки в формате, предпочтительном для его бухгалтерского софта (1C, SAGA, BAS и др.). Оценивается индивидуально после анализа.
Мы не выставляем от вашего имени. Подпись осуществляется с вашими учётными данными user-api под модуль e-Factura, генерируемыми отдельно в портале e-Factura SFS. Не общими учётными данными SFS, не USB-токеном для API — это стандартный метод согласно официальной документации.
Настройка учётных данных e-Factura в платформе (генерация user-api в портале SFS, подключение к модулю) — часы поддержки по запросу. В качестве альтернативы вы следуете нашей документации и настраиваете самостоятельно. Оценивается индивидуально после анализа.
Данные обработанных через платформу счетов остаются в оперативном кэше на наших серверах для быстрого поиска по истории. Официальный источник — SFS (система e-Factura); мы не являемся источником истины. Связь с API SFS идёт по HTTPS с проверкой сертификата.
Каждое действие (выставление, аннулирование, сторнирование, корректировка) фиксируется с указанием кто, что, когда, зачем — неизменяемая история. Полезно при любой фискальной проверке или обсуждении с бухгалтером.
Честность продаёт лучше широких обещаний. Вот реальные границы процесса B2B в малом магазине.
Подпись остаётся с вашими учётными данными. Мы — технический канал, который автоматизирует, а не юридический подписант.
Быстрое подтверждение счёта предполагает работающий API SFS. Если API SFS не отвечает, счёт остаётся черновиком — вы отправляете его повторно, когда SFS снова становится доступен.
Массовый перенос счетов, выставленных ранее в другой системе (для истории), ⚙️ обсуждается индивидуально — данные из разных систем могут быть крайне разнородны по формату и структуре, поэтому мы не можем дать стандартную оценку. Обсуждаем в каждом отдельном случае после того, как увидим источник.
Нативный экспорт: 1C, SAGA, BAS. Другие молдавские системы — добавляем формат по запросу (оценивается отдельно). Кастомная двусторонняя интеграция = ⚙️ доступно по запросу, обсуждается индивидуально.
Да. Без лимита, в пределах трафика вашего пакета. Мы не тарифицируем за документ — выставляете 10 или 500 счетов в месяц из магазина, ежемесячная стоимость (150 MDL) не меняется. Учёт идёт по трафику + месту, щедро включённым в тариф.
Разница в шаге IDNO + подтверждение SFS. IDNO, сканированный или введённый, автозаполняется из базы SFS (несколько секунд), а официальное подтверждение SFS приходит максимум за 5 секунд при обычных условиях. Итого: несколько секунд плюсом к кассовому чеку B2C.
Система проверяет IDNO в базе SFS. Если его нет (компания не зарегистрирована в SFS), мы получаем ограничение, и счёт не может быть выставлен на этого покупателя. Решение: покупатель регистрируется в SFS, либо выбираете простой фискальный чек (без e-Factura).
Настройка учётных данных user-api в платформе (генерируются отдельно в портале SFS) — часы поддержки по запросу — оцениваем в часах после анализа. В качестве альтернативы вы следуете нашей документации и настраиваете самостоятельно.
Нет. e-Factura работает автономно из POS. Бухгалтер может получать счета через API ERP — по индивидуальному запросу строим логику выгрузки в формате, предпочтительном для его бухгалтерского софта (1C, SAGA, BAS и др.), оценивается индивидуально после анализа. Ваши данные остаются доступны в режиме self-service через экспорт в любой момент.
Технически да — производительность не деградирует на объёме. Но если у вас постоянно большой трафик или объёмный каталог, размерность Micro (500 МБ хранения, 2 ГБ трафика / мес) может стать тесной, и мы рекомендуем более высокий тариф или дополнения — честно, на консультации оцениваем вместе.
Приведённые структуры отражают наше стандартное предложение, но каждый клиент обсуждается индивидуально. Мы адаптируем объём работ, сроки внедрения и специфические настройки под ваш бизнес. Финальное обязывающее предложение — то, что указано в письменной котировке + подписанном договоре.
20 минут по телефону: расскажем, что именно нужно с вашей стороны SFS (генерация учётных данных e-Factura), как выглядит внедрение, сколько времени займёт до первой live-фактуры из магазина. Тариф Micro стартует от 150 MDL/мес, с e-Factura без лимита в комплекте. Без обязательств, без длинных sales-питчей.
Смотрим вместе 20 минут на ваш магазин — оцениваем, подходит ли SGApps под ваш объём счетов B2B, как выглядит внедрение e-Factura, что подготовить со стороны SFS. Первичная консультация бесплатна.
SGAPPS LABS SRL · Кишинёв, Молдова · В непрерывной эксплуатации с 2018 · POS · ERP · Фискальный регистратор MEV · e-Factura SFS