Este artículo describe la correspondencia entre el Modelo de Objetos de Documento (DOM) de RetailForce y el modelo iEKA lituano.
Correspondencia de documentTypes
En Lituania, se establece una distinción básica entre los siguientes tipos de documentos (denominados «tipo de documento»):
- FiscalReceipt: transacciones de venta
- nonFiscalReceipt: documentos con fines diversos
- FiscalDay: informe de cierre diario
Dentro de los «NonFiscalReceipts», existen otros tipos que sirven para establecer distinciones adicionales.
Todos los tipos (FiscalReceipt, NonFiscalReceipt, FiscalDay) deben enviarse al sistema iEKA y, por lo tanto, se consideran «documentos fiscales» según la definición de RetailForce, es decir, documentos sujetos a fiscalización. En el caso de las cajas registradoras que operan con un módulo de seguridad, dicho módulo firma digitalmente los datos de los recibos fiscales, los recibos no fiscales y los informes de cierre diario (Z), conforme a lo especificado por la Inspección General de Hacienda de Lituania (VMI).
| Lituania | DocumentType de RetailForce | ||||
| Tipo | Tipo | Descripción | N.º |
Descripción | Notas |
| reciboFiscal | recibo | Comprobante de caja registradora: venta de bienes o servicios | 0 |
Recibo | - |
| recibo fiscal | recibo | Recibo nulo | 1000 |
Recibo nulo | - |
| nonFiscalReceipt | Documento de devolución no fiscal | Recibo de caja registradora para el registro de devoluciones, cambios y reembolsos | 0 |
Recibo |
Se trata del mismo tipo de documento que un recibo de caja registradora estándar. Correspondencia: SI
|
| nonFiscalReceipt | documento de cancelación no fiscal | Interrupción de una transacción antes de su finalización, transacción incompleta | 0 |
Se genera un | Se genera al llamar al punto final POST /api/v1/transactions/cancelDocument. |
| - | - | - | 1 |
Factura | Actualmente no es compatible |
| - | - | - | 2 |
Albarán | Actualmente no compatible |
| nonFiscalReceipt | Documento de cobro no fiscal |
Operación de pago, retirada de efectivo de la caja | 10 |
Pago | Las operaciones de pago deben transmitirse con valores NEGATIVOS (GrossValue, importe, etc.). |
| nonFiscalReceipt | Documento financiero no fiscal |
Operaciones especiales relacionadas con farmacias | 10 |
Pago | Actualmente no disponible |
| nonFiscalReceipt | Documento de cobro no fiscal | Operaciones de ingreso, p. ej., ingreso de cambio | 11 |
PayIn | Las operaciones de PayIn deben transmitirse con valores POSITIVOS (GrossValue, Amount, etc.) |
| nonFiscalReceipt | Documento financiero no fiscal | Operaciones especiales relacionadas con farmacias | 11 |
PayIn | Actualmente no disponible |
| - | - | - | 12 |
Factura proforma | Actualmente no compatible |
| - | - | - | 13 |
Pedido de cliente | Actualmente no es compatible |
| - | - | - | 14 |
PreliminaryReceipt | Actualmente no compatible |
| - | - | - | 15 |
Recibo de pago | Actualmente no compatible |
| - | - | - | 80 |
LongTermOrder | Tipo de documento admitido |
| nonFiscalReceipt | Documento de cobro no fiscal | Operaciones de ingreso, p. ej., ingreso de cambio | 90 |
OpeningBalance | se considera un ingreso PayIn |
| nonFiscalReceipt | documento no fiscal | «Informe (X)» — informe provisional | 98 |
CashCheck | Se puede generar un «CashCheck» mediante el punto final GET /api/v1/closing/{clientId}/endofdayDocument. No obstante, antes de ejecutar la operación /storeDocument, es necesario ajustar documentType y documentCaption según corresponda |
| día fiscal | día fiscal | «Informe (Z)»: informe de cierre diario | 99 |
EndOfDay | Es posible generar un documento «EndOfDay» mediante el punto final GET /api/v1/closing/{clientId}/endofdayDocument y almacenarlo mediante storeDocument. |
| - | - | - | 100 |
Inventario | Actualmente no disponible |
| nonFiscalReceipt | Documento financiero no fiscal | Estructura «Otras operaciones de cobro en efectivo» (collectionType: 3 – compra) | 101 |
Compra | - |
| - | - | - | 1001 |
Impresión de recibo | Actualmente no compatible |
| - | - | - | 1100 |
Varios no fiscales | Actualmente no es compatible |
Asignación de PaymentType
La siguiente tabla muestra los métodos de pago descritos en la documentación técnica del sistema lituano iEKA y su asignación a RetailForce DOM.
| <paymenttype> iEKA Lituania</paymenttype> | «PaymentType» RetailForce | Notas | |
| 1 - Efectivo | Efectivo | 0 |
Pago en efectivo |
| 2 - Pago con tarjeta de débito o crédito | EcCard | 1 |
Pago con tarjeta de débito |
| 2 - Pago con tarjeta de débito o crédito | CreditCard | 2 |
Pago con tarjeta de crédito |
| 3 - Otro medio de pago (p. ej., tarjeta de fidelización) | Loyalty | 13 |
|
| 4 - Bonos | MultiPurposeVoucher | 4 |
Los vales de uso único (3) no son compatibles actualmente como «PaymentType», sino que deben transferirse en el elemento «positions». |
| 5 - Giro postal | BankAccount | 11 |
Pago mediante transferencia bancaria |
| 6 - Reembolsado con cargo al presupuesto de la Seguridad Social | no admitido |
|
|
| 7 - Reembolsado con cargo al presupuesto del Estado | no compatible |
|
|
| 8 - Criptomoneda | Criptomonedas | 9 |
|
| 9 - Otros | No compatible |
|
|
| Estructura «OtherCashCollectionOperations» (collectionType 1 – ingreso) | Ingreso | 6 |
No se admite en Lituania como método de pago específico, sino como operación de recaudación de efectivo. |
| 10 - Redondeo |
|
no constituye un método de pago independiente en RetailForce, sino que se representa mediante el elemento «redondeo» (DocumentPosition.rounding). | |
| NoCash | 7 |
Actualmente no es compatible | |
| Ninguno | 8 |
No compatible actualmente | |
| Aplicaciones para teléfonos móviles | 10 |
No compatible actualmente | |
| Tarjeta de cliente | 12 |
Actualmente no compatible | |
| Cheque | 14 |
Actualmente no disponible | |
| CreditNote | 15 |
No es compatible actualmente | |
Asignación de BusinessTransactionType
Los BusinessTransactionTypes de RetailForce se asignan esencialmente a las denominadas «operaciones» en Lituania.
| Lituania | RetailForce | |
| Operación | N.º |
BusinessTransactionType |
| Operación de ventas | 0 |
Ingresos |
|
Descuentos adicionales: no se admite Se rechazan las posiciones con este BusinessTransactionType. Los descuentos se transmiten como «Descuentos adicionales» a través de los descuentos de una posición. |
1 |
Descuento |
| Operación de pago (collectionType 1 – ingreso) | 2 |
Depósito de envases vacíos |
|
PaymentType 4 – vales PayOutType 4 – vales |
3 |
Vale de uso único |
Otras operaciones de recogida de efectivo (collectionType 2 – otras) |
4 |
MultiPurposeVoucher |
|
No registrado En la legislación lituana, las propinas no se consideran una operación comercial en el sector minorista o de la hostelería. Se tratan como ingresos personales. |
5 |
Propina |
| No se registra. | 6 |
Propina de empresa |
| PayIn operación (collectionType 1 – ingreso) | 7 |
Ingreso |
| Otras operaciones de cobro en efectivo (dirección de cobro OUT) | 10 |
Pago |
| Otras operaciones de recaudación de efectivo (dirección de recaudación IN) | 11 |
PayIn |
| Otras operaciones de recaudación de efectivo (dirección de recaudación: IN o OUT) | 90 |
Transferencia de Fondos |
|
Documento de cobro no fiscal (dirección de la operación: OUT) Solo en los documentos con documentType [10] = Pago; en los documentos de PayIn [11] y OpeningBalance [90] se produce un error. El pago requiere el UniqueReadablePaymentIdentifier «Movimiento de efectivo». |
91 |
Diferencia de efectivo |
| No compatible | 92 |
|
| No compatible | 93 |
|
collectionTypes
El resto de las operaciones de pago se representan mediante «collectionTypes».
| Lituania | RetailForce | |
| collectionType | N.º |
Correspondencia |
| Depósito | 1 |
PaymentType: [6] = Depósito BusinessTransactionType: [7] = Depósito |
| Otros | 2 |
BusinessTransactionType: [4] = MultiPurposeVoucher BusinessTransactionType: [3] = Vale de uso único con valores negativos |
| Compra | 3 |
DocumentType: [101] = Compra |
| Reembolso | 4 |
SI:
|
El sistema RetailForce registra la comunicación con el sistema iEKA. Estos datos de depuración se almacenan en el directorio C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.
Para obtener más información, consulte el artículo «Comunicación con iEKA».
Este artículo ha sido traducido automáticamente.
Comentarios
0 comentarios
Inicie sesión para dejar un comentario.