OE is a stand alone system that processes orders in similar way to Sales Ledger Invoicing.
OE was found at a website that has archived files related to the Tandy TRS-80 computer running under Xenix (a *nix O/S from Microsoft) and this is defunct and has been for many years - well soon after the release of Linux any way.
The application was written for use with the RM Cobol compiler around v1.4 around 1979 - 1981 and for use on computers using such operating systems as CPM, MSdos, Windows v3.1 & 95 all with a small Ram size such as 640KB to 1Mb, As such the amount of Ram available for an application is very small so programming techniques used had to consists of breaking down the functions into small elements for each program, i.e., for file maintenance having seperate programs for Add, Update, Delete, Displaying and Reporting of say stock items.
OE programmers went one bigger by also having programs that handled printing with modules for 80 column and 132 column paper (I have also added one for 83 wide paper that i set to fit to page.
Another is Screen which handles all I/O to screen and input from the keyboard.
This last one no doubt worked with RM Cobol but does NOT with any other including GnuCobol so a lot of changes are required including adding an experimental C routine for accepting numeric values into COMP fields and this seems to b working well during testing.
It is currently an independant system and NOT linked in any way to ACAS at this point in time but is complete enough for testing and playing with but be warned the is very limited documentation. Just one manual as a .pdf file containing the system specifications including OE sub system program , file, screen and report layouts.
I have now added another document OE User Manual.pdf along with the input file when using LibreOffice Writer although it should also work for a modern version of Word but as I do not have it - it is not tested.
Over the course of migration to using the GnuCobol compiler report, screen and some file layouts have changed - mostly because some file fields have been increased in size to match those used within ACAS.
The primary feature of OE is the direct use of BO (Back Ordered) stock items but as of today I have not tested this area to see in detail how it works. Also the use of the screen program for accepting numbers has its problems which is where the new C routine written by Chuck is being used and this, so far is working well so may well be introduced into new coding in ACAS subject to available time - mine !
What has been tested is :
Initial file creation including the primary system files such as Company, Customer, and AR/SL code and tax files with the rest just created for further processing in Menu Option S.
Menu Options A through E and many others but with some exclusions - see the file README for details where the lastest entry is at the bottom and the file changelog for general system changes.
All program source have their own list of chamges as they have happened - same as in ACAS programs.
The individual program changes are mostly for programmer infomation so that a change that created a bug can be used to search for other programs that have had a similar change that can be fixed at the same time, etc.
OE migration - Well this depends on if the one feature OE has is the BO (Back Order) functions subject to how well it works and to consider introducing it into the Sales invoicing system and integrating OE into ACAS. This does have some issues as common type files having differeing fields used such as for the stock Item file has three levels of pricing (to handle discounts for bulk purchase) where ACAS using a entry by entry discount ability and an overall invoice discount facility. Also Customer records have specific TAX codes, discounts and other options that are in ACAS in a different form.
All those differences will have to be taken into account for a formal migration into ACAS. As well as migration file usge over to the ACAS ones.
It all depends on if adding OE into ACAS has a benefit to users so you are can provide feedback as to if this is a good idea and if you can to offer help in the work required and that includes writing a manual for it as the system spec is not good enough as a user manual.
This system is available as a nightly build archive file called OE-nightly.rar
2024/02/28 fixed typos.
Last edit: Vincent (Bryan) Coen 2024-02-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Addittional note : Sales invoicing when presented with a stock item (when using Stock-Linked) it display and is ready to accept the total number of items in stock.
You cannot select / input a higher value so ACAS in that sense does not support a back ordered amount other than allow any number to be input and using any values above quantity on hand to be marked as BO. invoices so flagged couldl be reported on both by stock items and customer for quantities but that would be about it. Note that OE does the same there is no process that allow BO item to be invoice once they come into stock. So really for both ACAS and OE it is a manual procedure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update for any company wishing to utilise BO (Back Orders) :
I am in the middle of adding BO to ACAS without using OE as the only feature it has over Sales ledger invoicing is in fact BO with a lot of ACAS features missing and the effort of adding them in is just silly, i.e., a lot of time involved. So the following is to be introduced to SL and invoicing at least for this time :
Taken from my system specification notes -
A. Change files system parameter file record - In fillers added fields SL-BO-Flag and Stk-BO-Active,
Change the parameter entry/amend program sys002 to support adding/changing these fields.
Done.
Adjust the way invoicing runs as at the moment it, having received the stock item ordered, show in quantity to invoice, total quantity onhand allowing user to change to that what is wanted.
On placing the (order line by line ) program changes stock by the order placed
Change above so that if SL-BO-FLAG = Y allow qty ordered to be above the onhand quantity where the onhand stock is used for this invoice and any extra is used to create or update an existing new ISAM (Indexed) file record as shown below for the purposes of reporting for new reports selected by user using a new program - to be written - see later.
New ISAM file: bostkitm.dat and dat.1, .2 and .3
1. Item # - Key 1 (Dups allowed )
2. Customer # Key 2 (dups allowed )
3. PO / order #
4. Order Date - extra index key Key 3 (dups allowed) may be for report based on date.
5. Original invoice # - for reference
6. Qty back ordered / requested.
7. Back Ordered stock expected arrival date if stored in stock record otherwise zero.
8. Current price - in case there is a price change with new stock received for reference.
New program sl970, to create reports of BO items by Customer (allowing for multi orders / items ) and by Items and possibly by original order date with the question on if file to be cleared after the reports produced.
If not, retained for future reporting or cleared if reports are final, etc.
As this file might be running 'as is', for many days / weeks before it needs to be cleared as final reports produced, say for a period / cycle , i.e., weekly or monthly
What ever. Only drawback to retaining the file after reports is that all other later reports will replace any previous ones and so will be cumulative.
Does depend on how busy the company is per day etc.
B. Another option is to retain file and when new stock comes in produce report show what BO orders can now be filled at this moment in time.
Of course before some one make a decision, raise a new invoice etc, a previous could come in it to reduce the new arriving stock.
The former method is the easiest to do though, as it only involves one new program possibly based on an existing stock report program, one new file and changes to the invoicing program to support it.
Invoicing program sl910 (entry) and sl920 (amend - batch mode only) changes to match with specifications.
New program sl970 to produce the three reports by option and a option to select data file clear down for end of BO cycle.
For option B this file would be a, always live file (not being cleared down) so it can be used as a input file for either Re-invoicing when fresh stock comes in OR to produce a report saying what can now be invoiced using the invoicing program sl910 and this is the easiest and less time consuming to do.
Option A is the fastest to do as B., will require another program and, or changes to the invoicing program to semi-automate these functions.
I should point out that most if not all businesses do use a manual method within the Sales department to process the work flow for back orders and to keep track of expected and actual inbound deliveries at least for out of stock items as well as special stock orders where any promotion in advance is in operation for what ever reason.
Any one have any points of view on the above other than option A ?
I am working on doing the changes needed for Option A any way as most of not all is required any way and it does support sales dept teams deal with their existing manual procedures.
Remember the issues with dealing with back order depend on the method of accepting an order such as prepaid (producing a rceipt) or on any credit terms (producing a Invoice) where the former could end up as producing a credit note or a refund. Is for prepaid orders the extra cost of P&P must be considered based on the profit margin of the sale for BO items especially so if there is multiple items on BO for a customer.
Kind of tricky asking a customer to foot the extra P&P bill when the business is the one at fault for not having stock.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the additions of Back Order processing now included in acas via sales ledger invoicing and stock control the usefullness of OE is reduced to the point of being not needed.
The only function now in OE that is not in acas is Salesman and sales commisions.
As OE has no link to a payroll system nor General / Nominal ledgers, I consider it as not worth the effort in migrating OE into ACAS.
However I have left the system in the nightlly builds for those that want to have a look see etc.
I have created a basic manual for it and the original system specification document is included but note that some fields have been made larger and therefore the screen and report layouts have been changed accordingly.
For Back Order provision in ACAS see the next post.
Last edit: Vincent (Bryan) Coen 2024-06-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The whole Back Order system as well as recurring charges for sales ledger and with some coding for Purchase has been completed.
I am very dubious as to using it in Purchase ledger though, so will not be added.
Also included in the nightly build as in cvs as of today is recurring processing for which new program sl800, sl810, sl820 and sl830 are complete and also included. THIS STILL HAS TO BE TESTED.
I have as of today not conducted any testing on these but will do so over the next few days if only to use the screens to update the manuals for Stock, Sales, Purchase.
In any event the manuals have had updates to them so some of the .pdf files have been updated. to match with the libreoffice open sourced file formats which should work with MF word but I have not tried it.
The cvs system has been updated to the current nightly build sources although I did try and use these as linked files but cvs is not too impressed and rejects them.
So much for making my life easier :(
Please report any issue to me here or via email or creating a bug report via tickets.
Last edit: Vincent (Bryan) Coen 2024-06-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As previously stated BO coding for Stock control is complete subject to full system testing.
Sales Ledger coding is still in progress regarding the Invoicing Program sl910 and this involves the following functions :
At start of program it checks if BO file and records exist then checks if any records has new stock added via a flag set in Stock control Stock Additions (st020) along with the quantity now added.
If the above is not the case it continues as previously allowing new orders to be input and invoices created.
If there are valid BO records with new stock it checks if the are any BO stock items for which there is more on BO orders than there is in stock and of so sets a flag to run in date of order only and this applies to ALL present BO records .
Otherwise will process in Customre / Stock Item order and this allows for mutiple orders per customer to be processed at the same time per new invoice.
This block of code is still being done - at least dry checking that the code is complete (but not yet) as I am still working on it. It is mostly complete but there might be the odd missing elements that need to be verified and fixed.
This BO code processing is active so I will be adding a question as if user wishes to procede with BO processing once the tests for BO records with new stock is present so user should currenttly say No to this question while this new code is still subject to changes. If the response is No then normal processing is run. This is the only way to stop BO processing and is a safegard.
I will update this with a later post when it is ready for formal testing and/or usage.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OE - Order Entry status -- This product is included for Cobol programmers to play with but it will NOT be included within ACAS. I have stoppped any work on it and that is not likely to change unless some one gives me a good reason to change my mind.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OE is a stand alone system that processes orders in similar way to Sales Ledger Invoicing.
OE was found at a website that has archived files related to the Tandy TRS-80 computer running under Xenix (a *nix O/S from Microsoft) and this is defunct and has been for many years - well soon after the release of Linux any way.
The application was written for use with the RM Cobol compiler around v1.4 around 1979 - 1981 and for use on computers using such operating systems as CPM, MSdos, Windows v3.1 & 95 all with a small Ram size such as 640KB to 1Mb, As such the amount of Ram available for an application is very small so programming techniques used had to consists of breaking down the functions into small elements for each program, i.e., for file maintenance having seperate programs for Add, Update, Delete, Displaying and Reporting of say stock items.
OE programmers went one bigger by also having programs that handled printing with modules for 80 column and 132 column paper (I have also added one for 83 wide paper that i set to fit to page.
Another is Screen which handles all I/O to screen and input from the keyboard.
This last one no doubt worked with RM Cobol but does NOT with any other including GnuCobol so a lot of changes are required including adding an experimental C routine for accepting numeric values into COMP fields and this seems to b working well during testing.
The OE system has been isssued on a nightly build basis via my website at http://www.applewood.linkpc.net/files/acas/nightlybuilds/ as is own archive named OE-nightly.rar
It is currently an independant system and NOT linked in any way to ACAS at this point in time but is complete enough for testing and playing with but be warned the is very limited documentation. Just one manual as a .pdf file containing the system specifications including OE sub system program , file, screen and report layouts.
I have now added another document OE User Manual.pdf along with the input file when using LibreOffice Writer although it should also work for a modern version of Word but as I do not have it - it is not tested.
Over the course of migration to using the GnuCobol compiler report, screen and some file layouts have changed - mostly because some file fields have been increased in size to match those used within ACAS.
The primary feature of OE is the direct use of BO (Back Ordered) stock items but as of today I have not tested this area to see in detail how it works. Also the use of the screen program for accepting numbers has its problems which is where the new C routine written by Chuck is being used and this, so far is working well so may well be introduced into new coding in ACAS subject to available time - mine !
What has been tested is :
Initial file creation including the primary system files such as Company, Customer, and AR/SL code and tax files with the rest just created for further processing in Menu Option S.
Menu Options A through E and many others but with some exclusions - see the file README for details where the lastest entry is at the bottom and the file changelog for general system changes.
All program source have their own list of chamges as they have happened - same as in ACAS programs.
The individual program changes are mostly for programmer infomation so that a change that created a bug can be used to search for other programs that have had a similar change that can be fixed at the same time, etc.
OE migration - Well this depends on if the one feature OE has is the BO (Back Order) functions subject to how well it works and to consider introducing it into the Sales invoicing system and integrating OE into ACAS. This does have some issues as common type files having differeing fields used such as for the stock Item file has three levels of pricing (to handle discounts for bulk purchase) where ACAS using a entry by entry discount ability and an overall invoice discount facility. Also Customer records have specific TAX codes, discounts and other options that are in ACAS in a different form.
All those differences will have to be taken into account for a formal migration into ACAS. As well as migration file usge over to the ACAS ones.
It all depends on if adding OE into ACAS has a benefit to users so you are can provide feedback as to if this is a good idea and if you can to offer help in the work required and that includes writing a manual for it as the system spec is not good enough as a user manual.
This system is available as a nightly build archive file called OE-nightly.rar
2024/02/28 fixed typos.
Last edit: Vincent (Bryan) Coen 2024-02-28
Addittional note : Sales invoicing when presented with a stock item (when using Stock-Linked) it display and is ready to accept the total number of items in stock.
You cannot select / input a higher value so ACAS in that sense does not support a back ordered amount other than allow any number to be input and using any values above quantity on hand to be marked as BO. invoices so flagged couldl be reported on both by stock items and customer for quantities but that would be about it. Note that OE does the same there is no process that allow BO item to be invoice once they come into stock. So really for both ACAS and OE it is a manual procedure.
Update for any company wishing to utilise BO (Back Orders) :
I am in the middle of adding BO to ACAS without using OE as the only feature it has over Sales ledger invoicing is in fact BO with a lot of ACAS features missing and the effort of adding them in is just silly, i.e., a lot of time involved. So the following is to be introduced to SL and invoicing at least for this time :
Taken from my system specification notes -
A. Change files system parameter file record - In fillers added fields SL-BO-Flag and Stk-BO-Active,
Change the parameter entry/amend program sys002 to support adding/changing these fields.
Done.
Adjust the way invoicing runs as at the moment it, having received the stock item ordered, show in quantity to invoice, total quantity onhand allowing user to change to that what is wanted.
On placing the (order line by line ) program changes stock by the order placed
Change above so that if SL-BO-FLAG = Y allow qty ordered to be above the onhand quantity where the onhand stock is used for this invoice and any extra is used to create or update an existing new ISAM (Indexed) file record as shown below for the purposes of reporting for new reports selected by user using a new program - to be written - see later.
New ISAM file: bostkitm.dat and dat.1, .2 and .3
1. Item # - Key 1 (Dups allowed )
2. Customer # Key 2 (dups allowed )
3. PO / order #
4. Order Date - extra index key Key 3 (dups allowed) may be for report based on date.
5. Original invoice # - for reference
6. Qty back ordered / requested.
7. Back Ordered stock expected arrival date if stored in stock record otherwise zero.
8. Current price - in case there is a price change with new stock received for reference.
New program sl970, to create reports of BO items by Customer (allowing for multi orders / items ) and by Items and possibly by original order date with the question on if file to be cleared after the reports produced.
If not, retained for future reporting or cleared if reports are final, etc.
As this file might be running 'as is', for many days / weeks before it needs to be cleared as final reports produced, say for a period / cycle , i.e., weekly or monthly
What ever. Only drawback to retaining the file after reports is that all other later reports will replace any previous ones and so will be cumulative.
Does depend on how busy the company is per day etc.
B. Another option is to retain file and when new stock comes in produce report show what BO orders can now be filled at this moment in time.
Of course before some one make a decision, raise a new invoice etc, a previous could come in it to reduce the new arriving stock.
The former method is the easiest to do though, as it only involves one new program possibly based on an existing stock report program, one new file and changes to the invoicing program to support it.
Invoicing program sl910 (entry) and sl920 (amend - batch mode only) changes to match with specifications.
New program sl970 to produce the three reports by option and a option to select data file clear down for end of BO cycle.
For option B this file would be a, always live file (not being cleared down) so it can be used as a input file for either Re-invoicing when fresh stock comes in OR to produce a report saying what can now be invoiced using the invoicing program sl910 and this is the easiest and less time consuming to do.
Option A is the fastest to do as B., will require another program and, or changes to the invoicing program to semi-automate these functions.
I should point out that most if not all businesses do use a manual method within the Sales department to process the work flow for back orders and to keep track of expected and actual inbound deliveries at least for out of stock items as well as special stock orders where any promotion in advance is in operation for what ever reason.
Any one have any points of view on the above other than option A ?
I am working on doing the changes needed for Option A any way as most of not all is required any way and it does support sales dept teams deal with their existing manual procedures.
Remember the issues with dealing with back order depend on the method of accepting an order such as prepaid (producing a rceipt) or on any credit terms (producing a Invoice) where the former could end up as producing a credit note or a refund. Is for prepaid orders the extra cost of P&P must be considered based on the profit margin of the sale for BO items especially so if there is multiple items on BO for a customer.
Kind of tricky asking a customer to foot the extra P&P bill when the business is the one at fault for not having stock.
With the additions of Back Order processing now included in acas via sales ledger invoicing and stock control the usefullness of OE is reduced to the point of being not needed.
The only function now in OE that is not in acas is Salesman and sales commisions.
As OE has no link to a payroll system nor General / Nominal ledgers, I consider it as not worth the effort in migrating OE into ACAS.
However I have left the system in the nightlly builds for those that want to have a look see etc.
I have created a basic manual for it and the original system specification document is included but note that some fields have been made larger and therefore the screen and report layouts have been changed accordingly.
For Back Order provision in ACAS see the next post.
Last edit: Vincent (Bryan) Coen 2024-06-30
The whole Back Order system as well as recurring charges for sales ledger and with some coding for Purchase has been completed.
I am very dubious as to using it in Purchase ledger though, so will not be added.
Also included in the nightly build as in cvs as of today is recurring processing for which new program sl800, sl810, sl820 and sl830 are complete and also included. THIS STILL HAS TO BE TESTED.
I have as of today not conducted any testing on these but will do so over the next few days if only to use the screens to update the manuals for Stock, Sales, Purchase.
In any event the manuals have had updates to them so some of the .pdf files have been updated. to match with the libreoffice open sourced file formats which should work with MF word but I have not tried it.
The cvs system has been updated to the current nightly build sources although I did try and use these as linked files but cvs is not too impressed and rejects them.
So much for making my life easier :(
Please report any issue to me here or via email or creating a bug report via tickets.
Last edit: Vincent (Bryan) Coen 2024-06-30
Status report as of this date :
As previously stated BO coding for Stock control is complete subject to full system testing.
Sales Ledger coding is still in progress regarding the Invoicing Program sl910 and this involves the following functions :
At start of program it checks if BO file and records exist then checks if any records has new stock added via a flag set in Stock control Stock Additions (st020) along with the quantity now added.
If the above is not the case it continues as previously allowing new orders to be input and invoices created.
If there are valid BO records with new stock it checks if the are any BO stock items for which there is more on BO orders than there is in stock and of so sets a flag to run in date of order only and this applies to ALL present BO records .
Otherwise will process in Customre / Stock Item order and this allows for mutiple orders per customer to be processed at the same time per new invoice.
This block of code is still being done - at least dry checking that the code is complete (but not yet) as I am still working on it. It is mostly complete but there might be the odd missing elements that need to be verified and fixed.
This BO code processing is active so I will be adding a question as if user wishes to procede with BO processing once the tests for BO records with new stock is present so user should currenttly say No to this question while this new code is still subject to changes. If the response is No then normal processing is run. This is the only way to stop BO processing and is a safegard.
I will update this with a later post when it is ready for formal testing and/or usage.
OE - Order Entry status -- This product is included for Cobol programmers to play with but it will NOT be included within ACAS. I have stoppped any work on it and that is not likely to change unless some one gives me a good reason to change my mind.