Μετάβαση από άλλο σύστημα

Όταν μια εταιρεία μεταφέρεται στο Nordlet από άλλο λογιστικό πρόγραμμα, τα βιβλία της δεν ξεκινούν από το μηδέν. Το εργαλείο εισαγωγής ιστορικών βιβλίων συγκεντρώνει όσα άφησε το παλιό σύστημα και τα καταχωρεί σε μία κλήση, μία λογιστική συναλλαγή στη βάση δεδομένων: εάν έστω και μία γραμμή αποτύχει στον έλεγχο, δεν αποθηκεύεται τίποτα. Το ίδιο πακέτο μπορεί να εκτελεστεί πρώτα μέσω ενός τελικού σημείου (endpoint) μόνο για έλεγχο, το οποίο εκτελεί κάθε επικύρωση και κάνει επαναφορά (rollback).

POST /v1/migration/books/validate   # ελέγχει τα πάντα, δεν γράφει τίποτα
POST /v1/migration/books/import     # γράφει τα πάντα ή τίποτα

Η εφαρμογή web διαθέτει τα ίδια δύο κουμπιά στην ενότητα Λογαριασμός → Μετάβαση (Account → Migration) (επικόλληση του JSON ή μεταφόρτωση αρχείου). Το κλειδί API απαιτεί το δικαίωμα ledger:write συν το δικαίωμα εγγραφής κάθε ενότητας που περιλαμβάνετε (partners:write, catalog:write, sales:write, purchases:write, assets:write, inventory:write). Και τα δύο τελικά σημεία (endpoints) δέχονται σώματα αιτημάτων έως 32 MB.

Η ημερομηνία μετάβασης (cut-over date)

Επιλέξτε την ημερομηνία μετάβασης (cut-over date): την πρώτη ημέρα λειτουργίας της εταιρείας στο Nordlet. Τα πάντα πριν από αυτήν παραμένουν στο παλιό σύστημα (ή μεταφέρονται ως ιστορικό, βλ. παρακάτω); τα πάντα από αυτήν την ημέρα και έπειτα καταχωρούνται στο Nordlet μέσω των κανονικών τελικών σημείων (endpoints). Όλα τα ποσά στο πακέτο είναι "ως την προηγούμενη ημέρα της μετάβασης": το ισοζύγιο κλεισίματος, τα τιμολόγια που παραμένουν απλήρωτα, τα αποθέματα στο ράφι, τα πάγια στο μητρώο.

Πριν από την εισαγωγή, κάντε τα εξής στο Nordlet:

1. Δημιουργήστε την εταιρεία και εφαρμόστε το πρότυπο λογιστικού σχεδίου (ledger/accounts/apply-template) - ή καταχωρίστε τους λογαριασμούς που χρειάζεστε στην ενότητα accounts του πακέτου.
2. Δημιουργήστε τουλάχιστον μία αποθήκη (inventory/warehouses/create) εάν εισάγετε αποθέματα.
3. Εκτελέστε το πακέτο μέσω του migration/books/validate έως ότου δεν αναφέρει σφάλματα και αποδεχτείτε τις προειδοποιήσεις του.

Το πακέτο

Κάθε ενότητα είναι προαιρετική; συμπεριλάβετε όσες διαθέτετε. Όλες οι αναφορές μεταξύ των ενοτήτων γίνονται με κωδικό (κωδικός λογαριασμού, κωδικός συνεργάτη, κωδικός είδους, κωδικός ομάδας παγίων, κωδικός αποθήκης), και ένας κωδικός μπορεί να αναφέρεται είτε σε εγγραφή που υπάρχει ήδη στο Nordlet είτε σε εγγραφή που δημιουργήθηκε από προηγούμενη ενότητα του ίδιου πακέτου.

{
  "cutoverDate": "2026-01-01",
  "source": "Rivilė GAMA",
  "accounts": [
    { "code": "6210", "name": "Advertising expenses", "type": "expense", "parentCode": "6" }
  ],
  "partners": [
    { "code": "301111222", "name": "UAB Klientas", "vatCode": "LT100001112223", "isCustomer": true },
    { "code": "302222333", "name": "UAB Tiekėjas", "isCustomer": false, "isSupplier": true }
  ],
  "items": [
    { "code": "SKU-1", "name": "Widget", "type": "product", "unit": "vnt", "vatRatePercent": "21" }
  ],
  "assetGroups": [
    { "code": "TRANSP", "name": "Vehicles", "assetAccountCode": "1230", "depreciationAccountCode": "1239",
      "defaultUsefulLifeMonths": 60 }
  ],
  "openingBalances": {
    "balancingAccountCode": "3410",
    "entries": [
      { "accountCode": "2710", "debit": "5000.00" },
      { "accountCode": "2410", "debit": "1500.00" },
      { "accountCode": "2040", "debit": "300.00" },
      { "accountCode": "1230", "debit": "12000.00" },
      { "accountCode": "1239", "credit": "2400.00" },
      { "accountCode": "4430", "credit": "700.00" },
      { "accountCode": "3010", "credit": "10000.00" }
    ]
  },
  "openReceivables": [
    { "partnerCode": "301111222", "number": "SF-1050", "issueDate": "2025-12-10", "dueDate": "2026-01-09",
      "grossTotal": "1210.00", "vatTotal": "210.00" },
    { "partnerCode": "301111222", "number": "SF-1049", "issueDate": "2025-11-20",
      "grossTotal": "500.00", "outstanding": "290.00" }
  ],
  "openPayables": [
    { "partnerCode": "302222333", "documentNumber": "T-77", "documentDate": "2025-12-15", "grossTotal": "700.00" }
  ],
  "fixedAssets": [
    { "groupCode": "TRANSP", "code": "CAR-1", "name": "Delivery van", "acquisitionDate": "2025-01-01",
      "acquisitionCost": "12000.00", "accumulatedDepreciation": "2400.00", "depreciatedMonths": 12 }
  ],
  "stock": [
    { "itemCode": "SKU-1", "quantity": "30", "unitCost": "10" }
  ]
}

Τα ποσά είναι συμβολοσειρές δεκαδικών αριθμών (decimal strings), όπως παντού στο API. Το source είναι μια ελεύθερη ετικέτα που καταλήγει στην περιγραφή της συναλλαγής αρχικών υπολοίπων και στις σημειώσεις των μεταφερμένων τιμολογίων.

accounts

Γραμμές λογιστικού σχεδίου: code, name, type (asset, liability, equity, income, expense), προαιρετικά parentCode και isPostable. Οι κωδικοί που υπάρχουν ήδη παραμένουν αເນπαφoi και καταγράφονται ως existing. Χρησιμοποιήστε το όταν το σχέδιο του παλιού συστήματος διαφέρει από το πρότυπο, ή παραλείψτε το και εφαρμόστε πρώτα το πρότυπο.

partners και items

Πελάτες, προμηθευτές και είδη καταλόγου, με κλειδί τον code. Στη Λιθουανία ο κωδικός συνεργάτη είναι συνήθως ο κωδικός μητρώου εταιρειών; για φυσικά πρόσωπα χρησιμοποιήστε οποιονδήποτε κωδικό είναι μοναδικός εντός της εταιρείας. Οι υπάρχοντες κωδικοί παραλείπονται και δεν ενημερώνονται. Τα είδη δέχονται type (product ή service), unit, barcode, vatRatePercent, salePriceExclVat, purchasePriceExclVat.

openingBalances

Το ισοζύγιο κλεισίματος του παλιού συστήματος, μία γραμμή ανά λογαριασμό: accountCode με debit ή credit. Οι γραμμές καταχωρούνται ως μία συναλλαγή ημερολογίου (journal transaction) με ημερομηνία openingBalances.date (προεπιλογή η ημερομηνία μετάβασης) και τύπο εγγράφου migration_opening. Οι γραμμές πρέπει να αναφέρονται σε λογαριασμούς που δέχονται εγγραφές (postable accounts).

Η συναλλαγή πρέπει να ισοσκελίζεται. Εάν το ισοζύγιο του παλιού συστήματος δεν ισοσκελίζεται - λόγω στρογγυλοποίησης, κέρδους που δεν έκλεισε ποτέ στην καθαρή θέση, ή ελλιπούς λογαριασμού - δώστε balancingAccountCode (συνήθως κερδος/ζημίες εις νέον, 3410 στο πρότυπο της Λιθουανίας) και η διαφορά καταχωρείται εκεί; η απάντηση αναφέρει το ποσό ως balancingAmount.

Μπορεί να υπάρχει μόνο μία συναλλαγή αρχικών υπολοίπων ανά εταιρεία. Μια δεύτερη εισαγωγή με openingBalances απορρίπτεται (409). Οι διορθώσεις εκ των υστέρων είναι συνηθισμένες χειροκίνητες συναλλαγές ημερολογίου (ledger/journal/transactions/create); οι καταχωρημένες συναλλαγές είναι αμετάκλητες, οπότε η αρχική παραμένει ως έχει εισαχθεί.

journal - πλήρες ιστορικό αντί, ή επιπλέον, των υπολοίπων

Εάν επιθυμείτε τις συναλλαγές του παλιού συστήματος στο Nordlet (ώστε να λειτουργούν οι αναφορές για προηγούμενες περιόδους), στείλτε τις εδώ: ένα αντικείμενο ανά συναλλαγή με date, προαιρετική description και reference, και entries από accountCode + debit/credit. Κάθε συναλλαγή πρέπει να ισοσκελίζεται από μόνη της. Καταχωρούνται με τύπο εγγράφου migration.

Οι ημερομηνίες πρέπει να είναι πριν από την ημερομηνία μετάβασης. Όταν το πακέτο περιέχει επίσης openingBalances, το ιστορικό πρέπει να έχει ημερομηνία την ή μετά την openingBalances.date - το συνήθες μοτίβο είναι υπόλοιπα στην αρχή του προηγούμενου οικονομικού έτους συν τις συναλλαγές αυτού του έτους, με τη μετάβαση την πρώτη ημέρα του τρέχοντος έτους. Μην στέλνετε υπόλοιπα και ιστορικό για την ίδια περίοδο: τα υπόλοιπα θα υπολογίζονταν διπλά.

Κάθε μήνας που επηρεάζεται από τα αρχικά υπόλοιπα ή το ιστορικό πρέπει να είναι μια ανοιχτή λογιστική περίοδος (αλλιώς επιστρέφεται 409).

openReceivables και openPayables

Τιμολόγια που παρέμεναν απλήρωτα (πλήρως ή μερικώς) κατά τη μετάβαση. Δημιουργούνται ως εκδοθέντα τιμολόγια πωλήσεων και καταχωρημένα τιμολόγια αγορών με paidAmount = grossTotal − outstanding, ώστε η αντιστοίχιση τραπεζών (bank/transactions/match, bank/transactions/suggest-matches), η αναφορά παλαιότητας απαιτήσεων (debt-aging report) και τα webhooks πληρωμών να λειτουργούν σε αυτά όπως σε κάθε άλλο τιμολόγιο.

• Το πεδίο outstanding έχει προεπιλογή το grossTotal; το vatTotal έχει προεπιλογή 0 (το καθαρό ποσό προκύπτει αυτόματα).
• Το dueDate έχει προεπιλογή την ημερομηνία του εγγράφου.
• Το currency έχει προεπιλογή το νόμισμα τιμολόγησης της εταιρείας. Για οποιοδήποτε νόμισμα εκτός του βασικού νομίσματος της εταιρείας, απαιτείται το fxRate - μονάδες αυτού του νομίσματος ανά 1 μονάδα του βασικού νομίσματος, η ίδια σύμβαση με την υπόλοιπη API - και αποθηκεύεται στο τιμολόγιο ώστε οι επόμενες πληρωμές να υπολογίζουν σωστά τη δεδουλευμένη συναλλαγματική διαφορά.
• Ο number του τιμολογίου πώλησης είναι ο πλήρης αριθμός του παλιού συστήματος και πρέπει να είναι μοναδικός στην εταιρεία. Τα τιμολόγια αγοράς είναι μοναδικά ανά συνεργάτη και documentNumber.
• Τα τιμολόγια δεν καταχωρούνται ξανά: το υπόλοιπο απαιτήσεων/υποχρεώσεών τους αποτελεί ήδη μέρος των αρχικών υπολοίπων. Συνδέονται με τη συναλλαγή αρχικών υπολοίπων, γι' αυτό και το openPayables απαιτεί openingBalances στο ίδιο πακέτο.
• Οι γραμμές τιμολογίων δεν εισάγονται; το τιμολόγιο περιέχει μόνο σύνολα. Το παλιό σύστημα παραμένει η πηγή για τις λεπτομέρειες των γραμμών και για τα βιβλία ΦΠΑ των περιόδων πριν από τη μετάβαση.

Εάν το παλιό σύστημα παρακολουθούσε τα υπόλοιπα πελατών χωρίς ανοιχτά στοιχεία, δημιουργήστε ένα τιμολόγιο ανά συνεργάτη για το υπόλοιπο (για παράδειγμα, αριθμός OB-301111222) ώστε να μπορεί να διακανονιστεί.

Η αρίθμηση συνεχίζεται. Όταν ένας εισαγόμενος αριθμός τιμολογίου πώλησης έχει τη μορφή PREFIX-N και η ημερομηνία έκδοσής του εμπίπτει στο έτος μετάβασης, η σειρά αρίθμησης για αυτό το πρόθεμα και έτος ορίζεται σε N + 1 (ποτέ δεν μειώνεται). Η απάντηση απαριθμεί την προκύπτουσα σειρά αρίθμησης numberSeries; για άλλες περιπτώσεις, ορίστε τη σειρά μόνοι σας με το reference/series/create ({ documentType: "sale_invoice", prefix, year, startAt }).

assetGroups και fixedAssets

Τα πάγια περιουσιακά στοιχεία μεταφέρονται μαζί με τις αποσβέσεις τους έως την ημερομηνία αυτή: acquisitionCost, salvageValue, accumulatedDepreciation, depreciatedMonths και usefulLifeMonths (ή η προεπιλογή της ομάδας). Η μέθοδος σταθερής απόσβεσης (assets/depreciation/post) συνεχίζει από την εναπομείνασα αξία επί των εναπομεινάντων μηνών. Τα πάγια των οποίων η συσσωρευμένη απόσβεση εξισώνεται ήδη με την αποσβέσιμη αξία δημιουργούνται ως fully_depreciated (πλήρως αποσβεσμένα). Τίποτα δεν καταχωρείται - το κόστος και η συσσωρευμένη απόσβεση αποτελούν μέρος των αρχικών υπολοίπων.

Οι ομάδες ορίζονται με βάση τον code και απαιτούν assetAccountCode και depreciationAccountCode (προεπιλεγμένος λογαριασμός εξόδων 6206).

stock

Απόθεμα σε χείρας ανά είδος: itemCode, quantity, unitCost (κόστος ανά μονάδα σε EUR) και προαιρετικά warehouseCode (προεπιλογή: η προεπιλεγμένη αποθήκη), lotNumber και expiryDate για είδη που παρακολουθούνται ανά παρτίδα ή σειριακό αριθμό. Κάθε γραμμή γίνεται εισερχόμενη κίνηση αποθέματος με ημερομηνία την ημέρα μετάβασης και τύπο εγγράφου migration και ξεκινά μια στρώση FIFO σε αυτό το κόστος. Τίποτα δεν καταχωρείται - η αξία των αποθεμάτων αποτελεί μέρος των αρχικών υπολοίπων.

Έλεγχοι και προειδοποιήσεις

Το τελικό σημείο επικύρωσης αποτυγχάνει (422) σε περιπτώσεις ελλιπών λογαριασμών, μη καταχωρήσιμων λογαριασμών, μη ισοσκελισμένων συναλλαγών, άγνωστων κωδικών συνεργάτη/είδους/ομάδας/αποθήκης, διπλότυπων κωδικών ή αριθμών εντός του πακέτου, ανοιχτών ποσών που υπερβαίνουν το μικτό ποσό, συσσωρευμένης απόσβεσης που υπερβαίνει την αποσβέσιμη αξία, και ελλιπών συναλλαγματικών ισοτιμιών. Αριθμοί ή κωδικοί που υπάρχουν ήδη στο Nordlet επιστρέφουν 409.

Επιπλέον, και τα δύο τελικά σημεία συγκρίνουν τα αναλυτικά καθολικά (sub-ledgers) με τις εγγραφές του γενικού καθολικού στο ίδιο πακέτο και επιστρέφουν τις διαφορές ως warnings (προειδοποιήσεις) και όχι ως σφάλματα:

• συνολικό ανοιχτό υπόλοιπο των openReceivables έναντι του υπολοίπου στον λογαριασμό απαιτήσεων (κανόνας καταχώρησης sales.receivable, 2410 εξ ορισμού);
• συνολικό ανοιχτό υπόλοιπο των openPayables έναντι του λογαριασμού υποχρεώσεων (purchases.payables, 4430);
• συνολικό κόστος του stock έναντι του λογαριασμού αποθεμάτων (inventory.stock, 2040);
• ανά ομάδα παγίων, το κόστος των παγίων έναντι του λογαριασμού παγίων της ομάδας και η συσσωρευμένη απόσβεσή τους έναντι του λογαριασμού απόσβεσης.

Μια προειδοποίηση σημαίνει ότι το αναλυτικό καθολικό (sub-ledger) του παλιού συστήματος και το γενικό καθολικό διαφωνούν. Διορθώστε το πακέτο (ή αποδεχτείτε τη διαφορά εν γνώσει σας) πριν προχωρήσετε στην εισαγωγή.

Η απόκριση

{
  "dryRun": false,
  "cutoverDate": "2026-01-01",
  "accounts": { "created": 1, "existing": 0 },
  "partners": { "created": 2, "existing": 0 },
  "items": { "created": 1, "existing": 0 },
  "assetGroups": { "created": 1, "existing": 0 },
  "openingBalances": { "journalTransactionId": "…", "date": "2026-01-01", "entries": 8,
                        "debitTotal": "18800.00", "creditTotal": "18800.00", "balancingAmount": "5700.00" },
  "journal": { "transactions": 0, "entries": 0 },
  "openReceivables": { "created": 2, "outstandingTotal": "1500.00" },
  "openPayables": { "created": 1, "outstandingTotal": "700.00" },
  "fixedAssets": { "created": 1, "costTotal": "12000.00", "accumulatedDepreciationTotal": "2400.00" },
  "stock": { "movements": 1, "costTotal": "300.00" },
  "numberSeries": [],
  "warnings": []
}

Το dryRun: true επισημαίνει μια εκτέλεση επικύρωσης (validate run); σε αυτή την περίπτωση, το journalTransactionId είναι null. Μια εισαγωγή καταγράφεται στο αρχείο καταγραφής ελέγχου (audit log) ως migration.imported με την ίδια σύνοψη.

Μετά την εισαγωγή

• Κλειδώστε τις περιόδους πριν από την ημερομηνία μετάβασης (ledger/periods/lock) ώστε να μην καταχωρηθεί τίποτα κατά λάθος στο μεταφερμένο ιστορικό.
• Ελέγξτε το ισοζύγιο και τον ισολογισμό κατά την ημερομηνία μετάβασης συγκρίνοντάς τους με τις αναφορές κλεισίματος του παλιού συστήματος.
• Συνεχίστε με τη συνήθη ροή: έκδοση τιμολογίων, εισαγωγή τραπεζικών κινήσεων, αντιστοίχιση πληρωμών - τα μεταφερμένα ανοιχτά τιμολόγια διακανονίζονται όπως ακριβώς και οποιοδήποτε άλλο.

Τι δεν καλύπτει το εργαλείο εισαγωγής: γραμμές τιμολογίων και βιβλία ΦΠΑ προηγούμενων περιόδων (διατηρήστε τα στο παλιό σύστημα ή στο αρχείο του), ιστορικό μισθοδοσίας και έγγραφα πέραν των τιμολογίων (παραγγελίες, δελτία αποστολής, συμβάσεις).

FAQ

• Μπορώ να εκτελέσω την εισαγωγή πολλές φορές; Ναι, αρκεί να χρησιμοποιήσετε το τελικό σημείο (endpoint) επικύρωσης (validate). Ωστόσο, η πραγματική εισαγωγή (import) αποτυγχάνει εάν υπάρχουν ήδη αρχικά υπόλοιπα ή αντικείμενα με διπλότυπους κωδικούς.
• Τι συμβαίνει εάν το ισοζύγιο αρχικών υπολοίπων δεν ισοσκελίζεται; Εάν δεν παρέχετε λογαριασμό εξισορρόπησης (balancingAccountCode), η επικύρωση θα αποτύχει. Αν τον παρέχετε, η διαφορά θα καταχωρηθεί αυτόματα σε αυτόν τον λογαριασμό.
• Μπορώ να εισάγω ιστορικό συναλλαγών χωρίς αρχικά υπόλοιπα; Ναι, αλλά συνήθως ο συνδυασμός και των δύο παρέχει την πληρέστερη εικόνα για την απρόσκοπτη συνέχιση της λογιστικής παρακολούθησης.