Payment Terms

In order for a company to be successful in today’s economy it must be diversified. This statement has been true for many companies around Michigan, especially those that are in the automotive sector. This trend holds true to all retail oriented businesses and the Beer industry hasn’t been immune. Along with recent consolidation we’ve also seen distributors adding new lines of products along with expanding into different type of business lines such as Craft, liquor, etc.

In order to address these changing needs eoStar is constantly evolving. We’ve added the ability to enter multiple payment terms to a single account. Previously the user was restricted to only 2 payment terms (alcoholic, and non-alcoholic). This is no longer the case you can now enter unlimited number of payment terms which correspond to a set of products. If a product is included in more than one product set, eoStar will use the payment term that is associated with the first payment term listed from top to bottom. eoStar will automatically partition an order if the customer is flagged to partition based on payment terms. The partition logic is currently only on the mobile device.

In addition to the above changes we’ve also added a new field in the payment terms table. It is called “Processing Method”. The processing method defines how eoStar should process the order. (I.e. via the Fintech interface, Miller UFF EDI, manually, or X12 EDI) This field was previously scattered in various panels of the application such as the EDI Partner> EDI setting screen. We also added a Fintech pre-fix for distributors that work with Chains that require a prefix on each invoice number to seperate product categories. In order to do so you must create a payment term for each product category and assign the proper Fintech prefix to each payment term.

We also removed the IsCharge and IsEFT columns from the customer table since the columns already exist in the payment terms table. This implies that any reports that currently use these columns will fail. Please make sure to test such report prior to installing the version in a live environment.

For “how to instructions” please go to the following wiki entry:
http://www.wiki-eostar.com/index.php?title=Payment_Terms

SRS error: Total # of records does not agree

“When distributors do not sell a supplier’s products on a certain day, VIP does not receive a file, which triggers a call to the distributor to inquire as to whether they had sales on that day. This can be avoided by creating a Zero Sales record for every day a file is created…A zero sales record can be either added to each day’s sales file segment for each supplier or only created for days when no sales are recorded.“

We’ve made modifications to the sales file to include the zero record in version 8.10.29 and higher. Unfortunately, we did not include the zero record entry in our calculation for the total number of records field which will result in the “Total # of records does not agree” error message from SRS. This has been addressed in version 8.11.5.

Ion depletion displying incorrect numbers

We were able to duplicate an issue that caused the ION depletion report to display incorrect inventory numbers. I would like to thank our users down south for helping us duplicate this bug. This issue manifested in a multiple warehouses database where the user would select additional warehouses beside the default warehouse (warehouse 1), and then move off the screen by going to the field selector or the date selector. The program would then only display the information for the newly selected warehouses and omitting the default selection which is the main warehouse; this resulted in incorrect inventory numbers. Our developers have addressed the issue in version 8.11.3 but as a workaround make sure you select the warehouse as a last step before running the report. (i.e. select the date range, field to display, etc., and then check the warehouses).

Bug fixes this week (11/3/08)

Development has been busy this week; we’ve fixed quite a few bugs or “features” depending on how you look at things. I just talked to a user and she was upset we fixed some of the printing bugs since she like the fact that the program would hang on to the printer.

1. Program no longer KABOOMS when viewing a purchase with no line items.

2. Corrected an issue where the printer setting where sticking to the crystal report resulting in all jobs going to the same printer.

3. Optimized the auto bump rules screens.

4. Optimized the performance to load and re-price orders within Recon.

5. Fixed a bug where the order would not highlight on the left deliveries grid upon clicking on a ticket number from the payment grid in reconciliation.

6. Fixed a bug in the reconciliation summary report where the report would print extra line items.

7. Corrected an issue in the price look up logic for returns in reconciliation.

And the biggest bug:
Fix the issue where the program would freeze when the user tried to fully synch but nothing happens. This bug was actually a .NetFrameWorks 3.5 issue, which is why it started once you upgraded to eoMobileCF 2008.

Here is the blog of relevance (scroll down to the threadpool stuff)
http://www.michaelckennedy.net/blog/default,date,2008-03-24.aspx

What's new this week ( 11/3/08)

You asked for it and we delivered:

1. SRS automation you can just set it and forget it. The program will automatically export your SRS data when you do a business day close out.

2. Added a new permission bit to prevent users from changing finalized purchases orders. ( tickets that have been reconciled via the supplier bill and freight bill queues)