Въпросите, изброени в тази статия, имат за цел да ви помогнат да проверите дали вашата имплементация на RetailForce Fiskal middleware отговаря на изискванията на германската Наредба за сигурност на касовите апарати (KassenSichV) в Германия.

Създаване на документи

• При създаването на касови бележки беше ли извикана функцията createDocument (за създаване на транзакция в TSE) при създаването на транзакция във вашата POS система?
  Контекст: В Германия се изисква да се започне транзакция в TSE при стартиране на документа (добавяне на първия артикул или клиент, или подобна дейност).

Предаване на документи

• Уверени ли сте, че всеки започнат документ е бил и предаден?
• Анулирането на касова бележка предава ли се като „cancelDocument“?
• Как се обработват анулиранията на редове?
• Как се обработват паркираните/суспендираните касови бележки (ако има такива) в края на деня?
• Проверява ли се постоянно броят на отворените транзакции на TSE?
• Осигурено ли е, че няколко процеса не комуникират едновременно с един и същ FiscalClient?
  (Не се допускат множество едновременни извиквания на storeDocument към един и същ FiscalClient, но се допускат множество FiscalClients за всеки FiscalService).
  
  • Как е реализирано обработването на грешки при буферирани повиквания (вижте също следващия въпрос)?
• Как е гарантирано, че към фискалната система се предават само документи, които са от значение за фискалните цели?
  
  • Каква е процедурата в случай на грешка?
• Как се справяте със ситуацията, при която услугата не е достъпна?
• Има ли „паркирани“/„суспендирани“ документи и ако да, реализирани ли са те чрез функцията LongTermOrder или чрез отворени транзакции на TSE?
  
  • Моля, имайте предвид, че различните производители на TSE поддържат различен максимален брой отворени транзакции на един TSE.
  • Вижте също: Процеси за дългосрочно поръчване в сектора на общественото хранене.
• Валидирането на документа беше ли извикано преди предаването или само когато методът storeDocument генерира грешка?

Видове документи

• Ще бъдат ли предадени всички типове документи, които имат значение за данъчното облагане?
  
  • Депозиране на ресто
  • Продажба
  • Внасяне
  • Изплащане/теглене
  • Налагане/теглене
  • Разлика в наличността
  • Касов баланс
• BusinessTransactionType задава ли се умишлено или винаги се оставя по подразбиране?
  
  • Кои от тях са внедрени?
  • Имате ли бизнес процеси, които все още не са съпоставени с BusinessTransactionType?
    (например: субсидии, които се осчетоводяват чрез POS системата (налична от версия 1.2.11)).
• Прехвърлени ли са правилно данъчните ставки за позициите?
• Прехвърля ли се правилно референцията в случай на анулиране или връщане?
• Предават ли се данните за клиента в случай на продажба, идентифицирана по клиент?
• Предава ли се потребителят (потребител на имота) заедно с документа?

Позиции

• Има ли други позиции, освен позициите на артикулите?
  
  • Набор от артикули
  • Отразявания / записване
  • Текстови позиции
• Как се отразяват евентуалните продажби с ваучер?
• Предават ли се отстъпките в съществуващата структура?
• За стойностите „NetValue“/„GrossValue“ на дадена позиция, предават ли се действителните продажби, реализирани за тази позиция, като се вземат предвид всички отстъпки (включително кумулативни отстъпки / отстъпки за междинни суми)?
• Предават ли се междинните суми?
• Има ли различни мерни единици?

Начини на плащане

• Настроени ли са правилно съответните PaymentTypes?
• Прави ли се разграничение между ваучери с еднократна и многократна употреба?
• За чуждестранните валути, прехвърлени ли са правилно обменният курс и валутата?

Касово приключване

• Извършено ли е приключването на касовата наличност?
• Ако се използва опростено приключване на касовата наличност, как се съгласуват/проверяват данните със системата?

Разпечатване

• Отпечатан ли е QR кодът върху всеки разпечатък/касова бележка?
• Отговаря ли разпечатката на законовите изисквания?
  
  • Вижте също: Задължение за издаване на касови бележки и изисквания към тях.
• Всяка разписка отпечатва ли се (или предоставя ли се в електронен формат) и връчва ли се на клиента?
• Отбелязана ли е евентуална грешка на TSE върху разпечатката?
• Включено ли е в разпечатката съобщението PrintMessage (задължително!) от fiscalResponse?

Работа

• Как е било гарантирано, че CloudConnect се извиква при рестартиране на услугата (и POS приложението не забелязва рестартирането, важи само ако архивирането в облака е активно)?
  
  • Беше ли съответно засечен кодът на отговора (424, неуспешна зависимост) за липсваща връзка с Cloud?
• Как е гарантирано, че услугата работи непрекъснато?
  
  • Инсталиран ли е мониторинг?
• Как се гарантира, че текущият трансфер в Cloud (архивирането) се проверява, за да се види дали работи правилно?
  
  • Използва ли се крайната точка /api/v1/information/client/{clientId}/status за непрекъсната проверка на отворените прехвърляния в облака?
• Осигурена ли е физическата (локална) близост на POS системата до фискалната услуга, както и до TSE?
  Вижте също често задаваните въпроси на BSI.

Технически въпроси/тестове

• Създадени ли са тестови единици за проверка на интеграцията?
  
  • Кои тестови случаи се обхващат от тестовите единици?
  • Кои бизнес случаи са обхванати от тестовите единици?
• Кои тестове и тестови протоколи са създадени?
• Как се обработва промяна в release-то на RetailForce? Тестовите единици се рестартират ли?
  
  • Как протича процесът на тестване?
• Гарантирано ли е, че в производствената експлоатация се използват само терминали (конфигурации) за производствена експлоатация?
• Гарантирано ли е, че не е възможно касовият апарат да работи без връзка с фискалното устройство и/или TSE?
• Гарантирано ли е, че не е възможно касовият апарат лесно да бъде отделен от фискалната система / техническото устройство за сигурност чрез конфигурация?

Тази статия е преведена автоматично.