Resumo
O Sistema NSP Auto encontra-se validado possuindo 100% de sucesso, ou seja, não ocorreu nenhum erro provocado pelo sistema ao longo da 1ª semana de validação( 21 a 28 de Junho,2005).
Resultados
Nº de transferências: 18
Nº de relatórios bem impressos : 16 (89%)
Nº de relatórios mal impressos por erro do sistema: 0 Nº de relatórios mal impressos por erro humano: 2 (11%)
Parâmetros de falhas:
Não leitura do código SSCC por parte do programa Scanner – 0% Não imprimir o NSP – 0%
Ocorrência de mensagens de erros, após pressionado o botão “Ok” – 0% Não transferência de dados do Scanner Symbol para o PC – 0%
Indicação errada do Peso da palete na NSP – 0%
A desactivação do sistema PGScanner durante não interferiu nos resultados obtidos. Para além da validação do sistema (software e equipamento) envolvido, foram realizadas algumas melhorias ao nível do programa Scanner, com vista a facilitar a utilização do mesmo por parte dos seus utilizadores.
Conclusão
Uma vez que não ocorreu nenhum erro/falha (0%) os resultados cumpriram o critério de sucesso (Falhas do sistema <= 10% das transferências).
Adicionalmente, pode-se concluir peremptoriamente que o sistema PGScanner que inclui o software PGScanner e o equipamento auxiliar (Leitor de código de barras, quadro eléctrico, foto célula, entre outros componentes), é dispensável.
Discussão
O sistema Auto NSP deve ser validado não porque funcionou durante a validação, mas principalmente porque o sistema permite fazer o rastreio das paletes, bem como detectar erros na impressão de etiquetas.
Relativamente ao sistema PGScanner a sua função deve ser discutida, existindo a possibilidade de o utilizar para outros fins, nomeadamente para permitir a impressão da etiqueta na hora exacta em que a palete chega ao paletizador. Esta funcionalidade permite melhorar o rastreio das paletes, pois estas passam a possuir na sua etiqueta a hora exacta de produção.
Electronic Data Interchange (EDI) is the computer-to-computer exchange of structured information, by agreed message standards, from one computer application to another by electronic means and with a minimum of human intervention. In common usage, EDI is understood to mean specific interchange methods agreed upon by national or international standards bodies for the transfer of business transaction data, with one typical application being the automated purchase of goods and services.
Despite being relatively unheralded, in this era of technologies such as XML services, the Internet and the World Wide Web, EDI is still the data format used by the vast majority of electronic commerce transactions in the world.
The EDI standards were designed from the beginning to be independent of lower- level technologies and can be transmitted using Internet protocols as well as private networks. It is important to differentiate between the EDI documents and the methods for transmitting them. While comparing the bisynchronous 2400 bit/s modems and value-added network to the Internet some people predicted erroneously that EDI would be replaced. These older transmission methods are being replaced by Internet Protocols such as FTP, telnet and email, although standards for these media are still emerging.
EDI documents contain the same data that would normally be found in a paper document used for the same organizational function. For example an EDI 940 ship- from-warehouse order is used by a manufacturer to tell a warehouse to ship product to a retailer. It typically has a ship to address, bill to address, a list of product numbers (usually a UPC code) and quantities. It may have other information if the parties agree to include it. However, EDI is not confined to just business data related to trade but encompasses all fields such as medicine (patient records, laboratory results..), transport (container and modal information...), engineering and construction, etc.
There are three major sets of EDI standards. UN/EDIFACT is the only international standard (in fact, a United Nations recommendation) and is predominant in all areas outside of North America.
The standard says which pieces of information are mandatory for a particular document, which pieces are optional and give the rules for the structure of the document. The standards are like building codes. Just as two kitchens can be built "to code" but look completely different, two EDI documents can follow the same standard and contain different sets of information. For example a food company may indicate a particular product expiration date while a clothing manufacturer would choose to send color and size information.
Organizations that send or receive documents from each other are referred to as "trading partners" in EDI terminology. The trading partners agree on the specific information to be transmitted and how it should be used. This is done in human readable specifications (also called specs or spec sheets). While the standards are analogous to building codes the specifications are analogous to blue prints. (The specification may also be called a mapping but the term mapping is typically reserved for specific machine readable instructions given to the translation software.) Larger companies have existing specification sheets and are usually unwilling to negotiate. Often in a large company these sheets will be written to be used by different branches or divisions and therefore will contain information not needed for a particular exchange. (Deviations from and clarification to the specification sheets should always be obtained in writing.)
Often missing from the specifications are real world descriptions of how the data should be interpreted. This is particularly important when specifying quantity. For example, suppose candy is packaged in a large box that contains 5 display boxes and each display box contains 24 boxes of candy packaged for the consumer. If an EDI document says to ship 10 boxes of candy it may not be clear whether to ship 10 consumer packaged boxes, 240 consumer packaged boxes or 1200 consumer packaged boxes. It is not enough for two parties to agree to use a particular qualifiers indicating case, pack, box or each; they must also agree on what that particular qualifier means.
EDI translation software provides the interface between the internal system and the
common standards. For an "inbound" document it typically takes the variable length fields of the EDI document, translates the individual pieces of data and then creates a file of fixed length fields. For an "outbound" document the translation software queries the internal system, as in the case of an SQL database, or it translates a fixed width file exported by the internal software. Translation software may also utilize other methods or file formats. The mechanism of translation is not part of the standard.
(In EDI terminology "inbound" and "outbound" refer to the direction of transmission of an EDI document in relation to a particular system, not the direction of merchandise, money or other things represented by the document. For example, an EDI document that tells a warehouse to perform an outbound shipment is an inbound document in relation to the warehouse computer system. It is an outbound document in relation to the manufacturer or dealer that transmitted the document.)