indica el país correspondiente.

Si se consultan las fiscalCountryProperties mediante la llamada GET /api/v1/information/client/{clientId}/countryProperties, se especifica el país asignado al cliente correspondiente.

Especifica si en un país se exige la certificación de un componente de fiscalización, o qué es lo que debe certificarse.

«obligatorio»: la certificación del sistema anterior (p. ej., la caja registradora) es obligatoria. En este caso, la caja registradora debe someterse a un proceso de certificación o homologación.

«miniPOS»: la certificación es obligatoria, pero se satisface mediante un componente ya certificado que puede integrarse en el RetailForce Middleware.

«notNecessary»: no se requiere certificación del sistema anterior.

«true» — En el país correspondiente, los datos deben enviarse línea por línea, por ejemplo, a una impresora fiscal.

• Actualmente no compatible

«false» — Interfaz basada en documentos (sin impresión línea por línea).

• La integración entre el sistema de origen y el Servicio de Fiscalización se realiza mediante puntos de conexión API estándar.

Especifica el tipo de fiscalización.

«fiscalPrinter» — La fiscalización se basa en una impresora fiscal certificada o en un sistema de caja registradora fiscal certificado.

• Esto implica que, además del sistema RetailForce, es necesario disponer de una impresora fiscal; es posible que deba adquirirse a un proveedor local.

«online»: fiscalización mediante los servicios en línea de las autoridades fiscales locales.

• No se requiere ningún componente de hardware adicional.

«signature»: fiscalización mediante la firma de los datos del recibo utilizando un certificado digital almacenado en el servicio de fiscalización.

• En algunos países, puede ser necesario obtener un certificado digital cualificado expedido por una CA (Autoridad de Certificación).

«signatureWithOnline»: fiscalización mediante la generación de firmas y la transmisión de datos en línea a las autoridades fiscales.

• Combinación de los dos tipos mencionados anteriormente.

Especifica qué entorno es compatible:

«local»: instalación local del middleware fiscal (en el propio sistema TPV, en el servidor de la tienda, etc.)

• Se pueden realizar llamadas a la API del servicio de fiscalización instalado localmente:
  • http://localhost:7678/ en el caso de la implementación REST, o
  • una llamada a un método en el caso de la implementación de NuGet.

«cloud»: el middleware fiscal está disponible como servicio alojado en la nube en https://fiscalisation.RetailForce.cloud/.

• Se pueden realizar llamadas a la API del Servicio de Fiscalización en la Cloud.

Especifica los sistemas operativos o plataformas compatibles.

«linux»

• a través de un contenedor Docker (implementación REST)

«windows»

• mediante un servicio de Windows (implementación REST), o
• mediante la implementación de NuGet

«iOS»

• mediante la implementación de NuGet

«Android»

• mediante la implementación de NuGet, o
• Servicio de Android (implementación REST)

Especifica los requisitos legales compatibles y sus versiones.

Por ejemplo, para Grecia: «myDATA v1.x.x».

Tipos de documentos que deben ser «fiscalizados» en el país correspondiente. Por ejemplo, deben ser procesados mediante el componente de hardware prescrito, firmados, etc.

Los «documentTypes» enumerados en «fiscalDocumentTypes» son procesados automáticamente (p. ej., firmados) en el país correspondiente por el servicio de fiscalización, de conformidad con la legislación en materia de fiscalización.

Estos tipos de documentos DEBEN transmitirse al servicio de fiscalización del país correspondiente, siempre que el sistema anterior («caja registradora») los admita.

Lista de tipos de documentos admitidos en cada país.

Además de los «fiscalDocumentTypes», los tipos de documentos que figuran en «supportedDocumentTypes» PUEDEN transmitirse al servicio de fiscalización.

Estos tipos de documentos se denominan «no fiscales», es decir, aquellos que no están «fiscalizados» (por ejemplo, firmados).

Lista de tipos de documentos no admitidos en el país correspondiente.

Los «documentTypes» que figuran en «notSupportedDocumentTypes» no pueden transmitirse al servicio de fiscalización en el país correspondiente.

Los motivos pueden ser la imposibilidad técnica o normativas y leyes específicas de cada país.

Si se envía un «notSupportedDocumentType» al servicio de fiscalización, este responderá con un mensaje de error («¡documentType no admitido!»).

El sistema de origen no debe permitir estos tipos de documento en el país en cuestión.

Lista de métodos de pago admitidos (aceptados) en el país correspondiente.

Estos métodos de pago pueden utilizarse en el país correspondiente.

El sistema upstream solo debe exponer al usuario de punto de venta los métodos de pago admitidos en el país correspondiente.

Lista de métodos de pago que no son compatibles (o no están permitidos) en el país correspondiente.

El sistema upstream debe omitir los métodos de pago no admitidos en el país correspondiente.

Lista de métodos de pago (PaymentTypes) para los que no se permite el pago en exceso del importe adeudado en el país en cuestión.

Ejemplos:

Importe total del recibo = 38,50 EUR

• El cliente abona 50 EUR mediante tarjeta de débito con el fin de recibir el cambio en efectivo.
• El cliente abona 50 EUR en efectivo y recibe 11,50 EUR de cambio (cambio entregado).

Estas transacciones no están permitidas en algunos países (es decir, no pueden enviarse al sistema de fiscalización).

Esto implica que los importes de pago («payment.amount») deben corresponder siempre al total bruto de las partidas («GrossValue» de todas las «positions») y no se pueden transferir importes de pago negativos.

Lista de tipos de casos de negocio admitidos en cada país.

Estos casos de negocio pueden utilizarse en el país correspondiente, a diferencia de los «notSupportedBusinessTransactionTypes».

Lista de tipos de casos de negocio que no son compatibles (o no están permitidos) en el país correspondiente.

Estos casos de negocio no pueden utilizarse en el país correspondiente y deben ser suprimidos por el sistema de origen y no transmitidos al servicio de fiscalización.

Información detallada sobre los tipos de Vat admitidos en cada país.

Esta matriz contiene la siguiente información:

• Tipo de IVA: «VatPercent» / «VatPercent2»
• ID interno utilizado para asociar el tipo de Vat correspondiente: «VatIdentification»
• Nombre del tipo de IVA: «caption» / «caption_EN»
• Tipos de Vat históricos con detalles de validez («ValidFrom» - «ValidTo»)

«no obligatorio»: no es necesario mostrar el cliente (sin obligación).

«obligatorio (sin RF)»: la visualización del cliente es obligatoria, pero no se controla a través del RetailForce Middleware. El control lo lleva a cabo automáticamente el sistema de fiscalización correspondiente (por ejemplo, automáticamente mediante la impresora fiscal).

«obligatorio (RF)»: es obligatorio utilizar una pantalla de cliente y el control se realiza a través del RetailForce Middleware.

• La pantalla del cliente se controla mediante la función: POST /api/v1/transactions/display/{clientId}

«no permitido»: el uso de una pantalla para el cliente está prohibido en este país.

Especifica si los dispositivos de entrada deben estar registrados en el país correspondiente («true» / «false»).

Los dispositivos de entrada no constituyen sistemas de registro autónomos. Para obtener más información, consulte: Arquitecturas de los sistemas de registro electrónico (EAS)

«true»: en el país correspondiente existe la obligación de llevar un registro técnico (registro de auditoría) (en este caso, incluido en la licencia RF).

• En este caso, las entradas de eventos técnicos deben enviarse al servicio de fiscalización mediante
  • POST /api/v1/transactions/AuditLog , o
  • POST /api/v1/transactions/storeDocument («documentType»: «[1002] = AuditLog»)

«false»: no existe la obligación de llevar un registro técnico (no incluido en la licencia).

• Los eventos técnicos PUEDEN registrarse, pero no es obligatorio hacerlo.

«true»: en el país correspondiente, la reimpresión de un documento debe registrarse de forma obligatoria.

• Realice una de las siguientes llamadas:
  • PUT /api/v1/transactions/reprintDocument/ {clientId}/{DocumentGuid}, o

  • PUT /api/v1/transactions/reprintDocument

    es obligatorio.

«false»: la reimpresión de un documento no tiene por qué registrarse como obligatoria.

«terminal»: el documento solo puede reimprimirse en la misma caja registradora en la que se emitió el documento original.

«store» — Las reimpresiones de un documento solo pueden realizarse en la misma sucursal o tienda en la que se emitió el documento original.

• La funcionalidad de reimpresión entre múltiples sucursales debe ser implementada por el sistema superior.

«all» — La reimpresión de un documento puede realizarse tanto en otra caja registradora como en otra sucursal o tienda de la misma empresa.

• La funcionalidad de reimpresión entre múltiples sucursales debe ser implementada por el sistema superior.

«true» — Se debe generar un cierre diario (informe Z) una vez al día.

• cierre diario
  • POST /api/v1/transactions/storeDocument
  • «documentType»: «[99] = EndOfDay»

«false»: no es obligatorio realizar un cierre diario.

Indica el intervalo de tiempo transcurrido desde la apertura diaria de la caja registradora en el que debe realizarse el cierre diario (por ejemplo, en un plazo de 24 horas).

«-1»: no se ha establecido.

Especifique si las ventas y las devoluciones pueden registrarse simultáneamente en un ticket (documento).

«oneReceiptAllowed»: permitido (las ventas y las devoluciones pueden aparecer mezcladas en un mismo ticket).

• Ventas:
  • «positions» (tipo 0 o 1) con valores positivos,
• Devoluciones:
  • «positions» (tipo 0 o 1) con valores negativos y
  • «documentReference» establecido.

«oneReceiptAllowedVat»: siempre que el importe del Vat sea positivo, las ventas y las devoluciones pueden registrarse en un único (el mismo) recibo.

«multiReceipt»: las ventas y las devoluciones deben registrarse en recibos distintos.

• Antes de transmitir los datos al servicio de fiscalización, el sistema anterior debe dividir automáticamente las ventas y las devoluciones en transacciones distintas.

«NoReturnAllowed»: en el país en cuestión, no es posible tramitar las devoluciones a través del sistema de fiscalización. En estos países, las devoluciones suelen gestionarse mediante formularios especiales o similares en el departamento de contabilidad.

¿Dónde pueden devolverse los artículos comprados?

«terminal»: los artículos solo pueden devolverse en la misma caja (emisión de ticket) en la que se realizó la venta original.

«store»: los artículos solo pueden devolverse en la misma sucursal o tienda (punto de emisión del ticket) en la que se realizó la venta original.

«all» — Los artículos también pueden devolverse en otras sucursales de la misma empresa.

Referencia del documento para devoluciones

«single» — En el caso de las devoluciones, solo se puede hacer referencia a UN ÚNICO documento anterior (documento de venta de los servicios o bienes devueltos).

• «documentReference»: únicamente se admite para un único documento preliminar, o
• la referencia a nivel de partida («positionReference») solo está permitida para un único documento preliminar.

«multiple»: en caso de devoluciones, se pueden hacer referencias a varios documentos anteriores (varios comprobantes de venta si se devuelven varios servicios o bienes procedentes de varias compras). 

• «documentReference» a varios documentos anteriores, o
• referencia al documento anterior correspondiente mediante «positionReference» en la partida individual de la devolución.

Especifica si el elemento «fiscalDocumentNumber» de la «fiscalResponse» del país correspondiente debe imprimirse en los documentos.

• Se ignoran los números de documento transferidos desde el sistema anterior. El sistema fiscal (p. ej., la impresora) asigna de forma autónoma el número de documento o el ID correspondiente.

«true»: en el país correspondiente, se permiten recargos sobre bienes o servicios.

• surcharges:
  • «positions.discounts» con valores NEGATIVOS

«false»: no se permiten recargos en los precios.

Indica si se permite el modo de formación o demostración del punto de venta en el país correspondiente

«true» — permitido.

• Modo de formación:
  • «IsTraining»: true

«false»: la caja registradora no debe disponer de modo de formación o demostración.

«true» — La suma de los artículos individuales se calcula a partir del importe neto (NetValue) (p. ej., Québec/Canadá).

«false» — La suma de los artículos individuales se calcula a partir del importe bruto (GrossValue) (por defecto).

«true»: las partidas que se hayan introducido pero que posteriormente no se incluyan en el documento deben transmitirse en la payload (JSON).

«false»: Las partidas que se hayan introducido pero que posteriormente no se incluyan en el documento no es necesario transmitirlas.

Especifica el tipo de documento inicial en el país correspondiente.

Solo es relevante si el sistema de origen NO utiliza la función GET /api/v1/transactions/document/{clientId}/start durante la inicialización y genera él mismo el documento inicial correspondiente.

Lista de tipos de pago admitidos en el país correspondiente.

Los elementos enumerados en «supportedPayOutTypes» pueden o deben especificarse para los pagos («documentType»: «[10] = PayOut» y «BusinessTransactionType»: «[10] = PayOut»).

Indica si los tipos del Vat son calculados por el módulo de fiscalización correspondiente del país.

«true»: el módulo de fiscalización calcula los tipos del Vat.

«false»: la caja registradora debe calcular los tipos del Vat.

Especifica si deben incluirse decimales en el documento JSON enviado al middleware fiscal al transmitir importes o totales, y en tal caso, cuántos.

Se aplica a todas las especificaciones de valores de la payload («GrossValue», «NetValue», «TaxValue», «Amount», etc.)