Data evaluation for cash flow planning

maxi commented

2019-05-24 15:30:00 +02:00

(Migrated from gitlab.weber-bodman.de)

No description provided.

maxi commented

2019-05-24 15:30:00 +02:00

(Migrated from gitlab.weber-bodman.de)

changed milestone to %20

maxi commented

2019-05-24 15:30:27 +02:00

(Migrated from gitlab.weber-bodman.de)

@agnes Please provide the exact information needed to do your daily work.

agnes commented

2019-05-27 16:57:30 +02:00

(Migrated from gitlab.weber-bodman.de)

the long-term goal is to collect the numbers and sums for the liquidity planning from inmax.
A report should be created, that shows me daily which invoice is due up to now or up to the current week. (With our without cash discount).
And similar: which customer has to pay this week- which didn't? This can also be combined with sending a payment reminder to customers.
steps:

(parallel) status for suppliers for the invoice: goods here-invoice not, invoice in the house, paid
determine payment condition for customers: in advance (with and without cash discount), 8 days 2% 20 days net, 10 days 2%, 30 days net. (payment conditions for suppliers already defined)
connect payment with inmax. ~~eg. with scanning the bar code after transferring/receiving money~~

Problems that may occur:

Sammelrechnungen: not every outgoing order gets an invoice!
Sammel-Bezahlung: not every invoice is paid separate (customers and suppliers side)

the long-term goal is to collect the numbers and sums for the liquidity planning from inmax. A report should be created, that shows me daily which invoice is due up to now or up to the current week. (With our without cash discount). And similar: which customer has to pay this week- which didn't? This can also be combined with sending a payment reminder to customers. steps: * [x] (parallel) status for suppliers for the invoice: goods here-invoice not, invoice in the house, paid * [ ] determine payment condition for customers: **in advance (with and without cash discount)**, 8 days 2% 20 days net, 10 days 2%, 30 days net. (payment conditions for suppliers already defined) * [ ] connect payment with inmax. ~~eg. with scanning the bar code after transferring/receiving money~~ Problems that may occur: * *Sammelrechnungen*: not every outgoing order gets an invoice! * *Sammel-Bezahlung*: not every invoice is paid separate (customers and suppliers side)

maxi commented

2019-07-16 23:14:15 +02:00

(Migrated from gitlab.weber-bodman.de)

@agnes 1st Report has been implemented recently: http://php-reports/report/html/?report=mysql/flow%20in.sql

maxi commented

2019-07-16 23:22:37 +02:00

(Migrated from gitlab.weber-bodman.de)

changed title from Data evalu{-t-}ation for cash flow planning to Data evaluation for cash flow planning

changed title from **Data evalu{-t-}ation for cash flow planning** to **Data evaluation for cash flow planning**

maxi commented

2019-07-16 23:23:26 +02:00

(Migrated from gitlab.weber-bodman.de)

@agnes having "parallel" order status is beeing implemented, now.

2nd report is for the due date of in/out invoices (next step).
how exactly could the information about cash discount be displayed?
i mean how could we deal with the different projections for different payments scenarios in the future (very complex)?

3rd point is the fun part (and easy, too) - which kind of device(s) do you prefer to use?
e.g. smartphone, tablet, webcam?
https://www.google.com/search?q=tischscanner+barcode&client=ubuntu&hs=Afs&channel=fs&source=lnms&tbm=isch&sa=X&ved=0ahUKEwie-czkrrrjAhXGLFAKHVSJDAgQ_AUIESgC&biw=1976&bih=1318

@agnes having "parallel" order status is beeing implemented, now. 2nd report is for the due date of in/out invoices (next step). how exactly could the information about cash discount be displayed? i mean how could we deal with the different projections for different payments scenarios in the future (very complex)? ~~3rd point is the fun part (and easy, too) - which kind of device(s) do you prefer to use? e.g. smartphone, tablet, webcam? https://www.google.com/search?q=tischscanner+barcode&client=ubuntu&hs=Afs&channel=fs&source=lnms&tbm=isch&sa=X&ved=0ahUKEwie-czkrrrjAhXGLFAKHVSJDAgQ_AUIESgC&biw=1976&bih=1318~~

maxi commented

2019-07-17 10:15:41 +02:00

(Migrated from gitlab.weber-bodman.de)

Dropdown (Coba, VoBa, SpK) when paying an invoice (default: VoBa) is needed.
Same thing for cash discount (mostly 2%, 1 and 3)

-> The dropdown should be directly in the payments list, so the payment could be changed when needed but no additional action should be needed by default.

All the information will be listed on the report "R-Listen".

- [ ] Dropdown (Coba, VoBa, SpK) when paying an invoice (default: VoBa) is needed. - [x] Same thing for cash discount (mostly **2%**, 1 and 3) -> The dropdown should be directly in the payments list, so the payment could be changed when needed but no additional action should be needed by default. All the information will be listed on the report "R-Listen".

maxi commented

2019-08-20 17:46:12 +02:00

(Migrated from gitlab.weber-bodman.de)

After having a closer look on the various software solutions beeing used during the payment process, I found a major issue:

Payments have to be triggered from invoice-max.

This is because inmax is the only database where all relevant information is present (order information and payment conditions).

I suggest that @agnes should do the initial triggering of payments and provide the transaction datasets (export) for Banking Software (VR Networld) and Bookkeeping Software (Lexware).

After having a closer look on the various software solutions beeing used during the payment process, I found a major issue: **Payments have to be triggered from invoice-max.** This is because inmax is the only database where all relevant information is present (order information and payment conditions). I suggest that @agnes should do the initial triggering of payments and provide the transaction datasets (export) for Banking Software (VR Networld) and Bookkeeping Software (Lexware).

maxi commented

2019-08-30 19:42:43 +02:00

(Migrated from gitlab.weber-bodman.de)

Side notes:

print payment conditions on invoices

Side notes: * [ ] print payment conditions on invoices

agnes commented

2019-11-18 15:20:32 +01:00

(Migrated from gitlab.weber-bodman.de)

for the php report 'R-Listen' multiple choice of Status is required to allow the printing of a report that includes all sequential invoices.

for the php report 'R-Listen' multiple choice of **Status** is required to allow the printing of a report that includes all sequential invoices.

agnes commented

2019-11-18 15:26:37 +01:00

(Migrated from gitlab.weber-bodman.de)

Each harbour trailer needs its own process because of the FIN number.
A problem are the so-called 'Sammelvorgang' which are created to combine delivery and invoice documents.
When the invoice is created, a payment entry is created. However, the transaction itself is only an aid and retains the status 'Correspondence with customer'. How can this be solved more elegantly?

Each harbour trailer needs its own process because of the FIN number. A problem are the so-called 'Sammelvorgang' which are created to combine delivery and invoice documents. When the invoice is created, a payment entry is created. However, the transaction itself is only an aid and retains the status 'Correspondence with customer'. How can this be solved more elegantly?

Rows
Columns

Data evaluation for cash flow planning #227